Re: GUERRE ST-AMIGA, FIGHT !!!

[astrofra]

Ce soir je suis descendu à la cave ranger des cartons.
J'y ai retrouvé 3 CDROMS avec des vieux fichiers Amiga, dont mon dernier projet en Lightwave / Scala MM réalisé quand j'étais étudiant aux Beaux Arts sur mon Amiga 2000 <3

http://amigamod.ghost.io/voyage-amiga-lightwave-3d-4-0-scala-mm200-1997/

J'ai réinstallé Scala MM sous WinUAE pour grabber le projet et l'uploader sur Youtube.
A vot'bon coeur.

[Invité]

en fait tu ne connais pas du tout ta machine !  comme je te le disais mais apparemment tu ignores mes propos, dis moi quel effet en temps réel était possible en HAM sur amiga ?? RIEN, NADA !!! le CPU n'est pas assez puissant pour modifier en temps réel une image HAM.
Le HAM c'est juste bon à afficher une image fixe, exactement comme le ferait un ST.   Pour ton bon souvenir, regarde la vitesse de traitement sur une image HAM, alors ils sont où tes SUPER copros ?  ( à 4:42 ). 

Ah bon tu est sur ???

2 exemples vite fait .

là, rotozoom en HAM :
https://youtu.be/2d1vAq6tPbs?t=1m33s

Et là, un scroll text sur image HAM :
https://youtu.be/Kfx7YgfV3mM?t=16s

[astrofra]

Le HAM c'est juste bon à afficher une image fixe, exactement comme le ferait un ST.

Des images fixes ?
Comme ici ?

https://youtu.be/Gf6erAxkW7Y?t=26s

[rocky007]

en fait tu ne connais pas du tout ta machine !  comme je te le disais mais apparemment tu ignores mes propos, dis moi quel effet en temps réel était possible en HAM sur amiga ?? RIEN, NADA !!! le CPU n'est pas assez puissant pour modifier en temps réel une image HAM.
Le HAM c'est juste bon à afficher une image fixe, exactement comme le ferait un ST.   Pour ton bon souvenir, regarde la vitesse de traitement sur une image HAM, alors ils sont où tes SUPER copros ?  ( à 4:42 ). 

Ah bon tu est sur ???

2 exemples vite fait .

là, rotozoom en HAM :
https://youtu.be/2d1vAq6tPbs?t=1m33s

Et là, un scroll text sur image HAM :
https://youtu.be/Kfx7YgfV3mM?t=16s

ben tu le sais très bien, il n'y a pas besoin de t'expliquer le CPU restant en HAM, certainement pas assez pour faire des effets lourds en temps réel ( comme le pensait Babsinov avec Scala ). sauf bien sûr en 80x50 

Voici la toute puissance  du CPU en HAM :

[rocky007]

Le HAM c'est juste bon à afficher une image fixe, exactement comme le ferait un ST.

Des images fixes ?
Comme ici ?

https://youtu.be/Gf6erAxkW7Y?t=26s

oui exactement... un AVI n'est qu'une succession d'images fixe, il n'y a aucune charge processeur

[astrofra]

Ah oui, donc ici, "image fixe" == "animation" ?
Je comprends mieux pourquoi, au bout de 25 pages, la discussion n'a pas avancé d'un pouce.

[Urbinou]

oui exactement... un AVI n'est qu'une succession d'images fixe, il n'y a aucune charge processeur

C'est assez épique comme réponse, ça   

Par contre, je ne savais pas que l'Amiga avait un decodeur video en hard

[Invité]

ben tu le sais très bien, il n'y a pas besoin de t'expliquer le CPU restant en HAM, certainement pas assez pour faire des effets lourds en temps réel ( comme le pensait Babsinov avec Scala ). sauf bien sûr en 80x50  

C'est quand même mieux que rien en 85 non ..
Je préfère un mode HAM utilisable juste pour le dessin, que 16 couleurs pour tout .
Et c'est pas le mode merdeux en 512 couleurs de neochrome qui me fera changer d'avis  

oui exactement... un AVI n'est qu'une succession d'images fixe, il n'y a aucune charge processeur

C'est faut, a un moment faut bien rafraîchir la RAM avec de nouvelles données, sauf bien sur si ton avi tient non compressé dans les 512 ko de ram (ce que je doute fort qd même), voire aussi faire de la décompression .

[rocky007]

à +- 100ko par image, ça ne doit pas prendre plus de 30% des cycles dispo

désolé de te contredire, mais le mode 512 / 4096 couleurs des ST et largement supérieur, car plus de couleur par ligne.  le HAM, c'était juste un truc pour les geeks qui étaient déjà myopes à la naissance

[astrofra]

Désolé de te contredire, mais le mode HAM est géré en hard et ne monopolise pas plus le CPU que les modes graphiques standards en 6 bitplans.

Le mode 512 couleur du ST n'est pas gratuit en temps CPU, lui.

[rocky007]

tu ne me contredis pas    mais comment gères-tu les chargements du disque dur dans la mémoire et le déplacement du le bloc chargé sur la page active sans CPU ?

[astrofra]

https://en.wikipedia.org/wiki/Amiga_Chip_RAM#Direct_memory_access

[Ninja_SCX]

Le mode HAM est effectivement une caractéristique Hardware de l'Amiga.
Le fait qu'il utilise 6 plans ralentit les accès du CPU à la "Chip-Memory" de l'Amiga.
Ce qui fait qu'en pratique ce mode était surtout utilisé pour l'affichage d'images fixes.
Après, on pouvait ruser en utilisant les sprites Hardware de l'Amiga pour afficher des animations par dessus une image en HAM, mais ça restait marginal.

Le mode 512 couleurs du ST était une bidouille logicielle pour changer la palette du ST plusieurs fois par ligne en utilisant les interruptions.
Cette bidouille aurait pu être utilisée sans peine sur Amiga également.

[rocky007]

https://en.wikipedia.org/wiki/Amiga_Chip_RAM#Direct_memory_access

oui et ?

[rocky007]

Le mode HAM est effectivement une caractéristique Hardware de l'Amiga.
Le fait qu'il utilise 6 plans ralentit les accès du CPU à la "Chip-Memory" de l'Amiga.
Ce qui fait qu'en pratique ce mode était surtout utilisé pour l'affichage d'images fixes.
Après, on pouvait ruser en utilisant les sprites Hardware de l'Amiga pour afficher des animations par dessus une image en HAM, mais ça restait marginal.

Le mode 512 couleurs du ST était une bidouille logicielle pour changer la palette du ST plusieurs fois par ligne en utilisant les interruptions.
Cette bidouille aurait pu être utilisée sans peine sur Amiga également.

nope car la copper est + limité ( 4 pxl / couleur si je me souviens bien )

[Invité]

à +- 100ko par image, ça ne doit pas prendre plus de 30% des cycles dispo

désolé de te contredire, mais le mode 512 / 4096 couleurs des ST et largement supérieur, car plus de couleur par ligne.  le HAM, c'était juste un truc pour les geeks qui étaient déjà myopes à la naissance

Oui, et c'est encore moins utilisable que le mode HAM, et surtout pas standard du tout, en plus de consommer énormément de CPU, n'oublies pas que le ST n'a aucune interruptions pour faire ça,à part ses 2 timers .

nope car la copper est + limité ( 4 pxl / couleur si je me souviens bien )

Mais là on touche à la palette, pas aux pixels .
Et y'a bien des plasmas au pixel de toutes façons non ??

[astrofra]

Le copper des Amiga OCS est effectivement limité à une instruction tous les 4 pixels, mais peut changer 16 couleurs d'un coup entre la fin d'une ligne et le début de la suivante.

Celui de l'AGA était plus précis/rapide, mais je n'ai pas les chiffres en tête.

Il a existé une mode HAM basé sur le copper, nommé "Sliced HAM", ainsi qu'une version en HIRES qui permettait d'afficher 16 couleurs par ligne en 640x512, en changeant de palette à chaque ligne, donc.

Le S-HAM n'est pas un mode officiel du chipset Amiga, mais plutôt une utilisation intelligente du copper.
Si j'arrive à en retrouver des exemples, je les posterai ici :)

Sinon, exemple d'utilisation du copper sur un jeu avec du graphisme interactif pour passer de 32 à 55 couleurs :

http://www.codetapper.com/amiga/maptapper/documentation/gfx/gfx-palette/

[astrofra]

En attendant, y'a ptet un moyen de mettre tout le monde d'accord sur une chose.

En 640x400, de base, un Amiga 500 affichait ça :


En 640x400, de base, un Atari 520 ST affichait ça : 


En 640x200, sur Amiga on avait ça :


... et sur Atari ST on avait ça :


Juste pour rappeler les faits, quoi.
(cliquez sur 'agrandir' sinon le tramage est bousillé)

[rocky007]

à +- 100ko par image, ça ne doit pas prendre plus de 30% des cycles dispo

désolé de te contredire, mais le mode 512 / 4096 couleurs des ST et largement supérieur, car plus de couleur par ligne.  le HAM, c'était juste un truc pour les geeks qui étaient déjà myopes à la naissance

Oui, et c'est encore moins utilisable que le mode HAM, et surtout pas standard du tout, en plus de consommer énormément de CPU, n'oublies pas que le ST n'a aucune interruptions pour faire ça,à part ses 2 timers .

nope car la copper est + limité ( 4 pxl / couleur si je me souviens bien )

Mais là on touche à la palette, pas aux pixels .
Et y'a bien des plasmas au pixel de toutes façons non ??

ben oui justement, le copper change la palette, pas les pixels.
c'est elle qui permet d'ajuster la palette voulue à la scanline voulue

du reste, l'effet bavant du HAM pourrait être compenser si parallèlement on pouvait modifier la palette manuellement en fonction de la scanline, hors cela n'a à ma connaissance jamais été fait.
( c'est pour cela qu'aucun jeu en ham existe, hormis des fond d'écran fixe, car selon la position du sprite, les contours du sprite serait un vrai bordel )

[rocky007]

En attendant, y'a ptet un moyen de mettre tout le monde d'accord sur une chose.

En 640x400, de base, un Amiga 500 affichait ça :

malheureusement ton image ne reflété pas le magnifique scintillement à rendre épileptique un phoque mononucléosé sur l'amiga..
et la parfaite stabilité et finesse de l'image du ST.

mais bon, je vois pas trop le but de dire "de base"... les tout premier logiciel de jeux et utilitaire utilisaient les rasters, c'était dans le devkit d'atari, donc cela faisait partie de la programmation "de base" du processeur graphique.

le but n'était pas d'avoir 512 couleurs, mais au moins 2 à 3 changements de palette par VBL pour obtenir un jeu plus colorés.

[astrofra]

Non, l'image du ST n'était pas parfaitement stable en 640x400 sur un moniteur couleur standard ou sur un téléviseur.
Et pour cause...

[rocky007]

jaloux

[astrofra]

Être obligé d'acheter 2 moniteurs pour accéder à 3 résolutions différentes. Bof. Non :)

[rocky007]

le moniteur haute résolution était pour ceux qui voulait bosser pro, par pour jouer... mais ça un amigaiste ne peut pas comprendre

[astrofra]

Moi tout ce que je vois c'est qu'en 640x200, sur Atari, c'était quand même pas joli joli :)
Je parle plus du 640x400 sinon on va encore repartir dans le catalogue des moniteurs noir & blanc  

[rocky007]

ben y'avait que 4 couleurs, donc forcément on sait pas faire de miracle
mais au moins ça ne scintillait pas..

[astrofra]

Mais d'où tiens-tu cette info qu'une image Amiga scintillait en 640x200 (16 couleurs, comme dans 4 fois 4) ?

(pour mémoire)

(edit : dire que c'est l'Amiga qui scintille en mode entrelacé dénote quand même une certaine lacune en matière de normes vidéo, mais bon, trop de troll tue le troll...)

[rocky007]

merci mais en général qd je veux une info, je me fie plus à wikipedia à un fanboy amiga qui ne semble pas vraiment comprendre les fondamentaux. 

utiliser le WB entrelacé était tout simplement horrible, mais aura fait la fortune des vendeurs de flicker fixer.

mais pour m'amuser comme toi, voici plutôt la réalité sur amiga/ST

[astrofra]

D'accord, mais d'où tiens-tu cette info qu'une image Amiga scintillait en 640x200 ?

[Ninja_SCX]

L'Amiga ne scintillait pas en 640x200 (640x256 même) mais scintillait en 640x400 (640x512 même).
Ce scintillement était dû non pas à l'Amiga en lui même mais à la limite du tube cathodique des télés standard de l'époque.
En utilisant un moniteur multiscan comme le M1438S, l'Amiga pouvait afficher du 640x512 en 16 couleurs sans scintillement.

[astrofra]

J'ai eu les deux machines. J'ai passé autant d'heures dans l'éditeur de source du GFA Basic que dans celui d'AMOS Basic. Les deux étaient dans la même résolution, jamais vu un seul scintillement à l'écran.

Du coup, je ne sais vraiment pas pourquoi @rocky007 écrit que la medres de l'Amiga produisait un scintillement ... Mais il va nous expliquer tout ça :)