(edit: pardon pour mon style de guinguoi mais je suis malade et arrêté aujourd'hui)
Comme je vois que msk s'interesse à la CD32, voilà quelques réponses à ses question, dans un nouveau fil pour pas pourrir celui sur NeoGeo... A noter qu j'ai ramassé une CD32 en état de marche dans un vide grenier il y a 3 ans, mais j'ai pas codé trop là dessus.
- La CD32 avait une carte mère différente de l'A1200 mais les chips principaux, et donc les specs de la machine, et meme un peu la ROM, étaient les mêmes: AGA pour la video, paula pour le son, le fameux "blitter" et un 68020 à (12 ou 14?)Mhz et 2Mo de chipram, comme le A1200.
(note: le A4000 c'est encore pareil sauf la memoire et les CPU qui ont plutot de la fast de base et des 68040 )
En fait tu trouves en crack pour CD32 des CD contenant de centaines de jeux AGA et ECS pour la plupart juste copié sur le CD.
Potentiellement, une CD32 peut donc directement faire tourner les demo pour A1200 "vanilla" (==conf de base), c'est à dire celles qui n'utilisent pas de fastram supplémentaire et s'en tiennent au 68020, avec les 2 Mb de chip.
Les demos vanilla AGA se caractérisent par le fait que dans cette conf, la machine est bien 2 a 4 fois plus puissante qu'un A500 ECS, mais pas encore assez puissante pour faire de la 3d en 320x240 ou 320x256, comme les PC commençait à le faire en 1995.
Example de demo A1200 Vanilla que j'aime bien, wildlife par abyss (qui date de 98 ou plus personne ne faisait de vanilla): on notera que la demo commence avec une c2p en 16 couleurs qui affiche un rotozoom. Ensuite, les effets sont soit en c2p, soit des effets blitter comme sur A500, soit les 2. C'est très hybride.
http://www.youtube.com/watch?v=fRsusQcnpAk#Sinon comme demo vanilla 1200 il y a bien sur roots de sanity, real de complex, ...
Donc à propos des technos AGA vanilla:
- le blitter AGA est au moins 4 fois plus rapide que celui des A500 (c'est ce que j'entendais à l'époque). et c'est le blitter, chargé de faire des copies 2D dans la chip, des opérations booléennes de bitmap, et des remplissage de polygones flat d'aprés des lignes, qui était utilisé par la plupart des demos A500.)
- LE cpu 68020 connait quelques instructions en plus que le 68000 (dont la multiplication 32x32-> résultat sur 64, enlevé/émulé ensuite sur 68040/060 !!!), mais surtout possédait un cache instruction de 256 octets, alors que le 68000 n'avait aucun cache ! (le 68030 a un cache instruction de 256, et un de donnée de 256, puis le 040/060 ont des caches en kilos)... C'est réellement a noter, car quand on se démerdait a mettre des calculs dans des boucles qui tenaient dans les 256 octets, le code courrait 4 fois plus vite ! (un 68000 passe le moitié de son temps a recharger le code qu'il exécute) -> ça a influencé le code de la plupart des C2P.
Voilà, sinon les demomakers amiga ont aussi pas mal joué avec la "copper list", qui permettait de changer les couleurs et le pointeur de la mémoire vidéo, par ligne horizontale, mais comme les sprites, ça a été massivement abandonné avec l'arrivé des cartes 68030/68060 ou là tout le monde est passé en chunky, point barre.
Sur CD32, il faudrait voir ce qu'on peut faire en streaming depuis le CD. En théorie on peut bosser avec un a1200/a4k+cdrom pour développer ça. Il serait peut etre possible de faire un genre de Mega-state-of-the-art en streamant de la video vectorielle sur le CD-ROM ou un truc comme ça. (la CD32 avait un décompresseur MPEG optionnel pour les films, très rare)
En fait, j'avais commencé a faire des shaders GLSL sur pc pour tester de la vectorisation de bitmap en temps réel, dans l'optique de faire une demo cd32 ensuite, mais c'est pas ma priorité !
Pour ce qui est des chunky to planar: Vers 1995, tout le monde voulait faire du texture mapping, et il y a eu plusieurs tentatives de technos plus ou moins concluante (voir les prods 3d amiga 93/94 avec leurs dithering baveux)
.. parfois on utilisait la copperlist et un dégradé horizontal, et on changeait la palette par scanline, pour faire des écrans chunky "copperscreen", mais ça permettait qu'une centaine de pixels en largeurs.
Le problème de la mémoire chip amiga, c'est que les écritures CPU sont lentes.
vers 1995, beaucoup de sources de c2p différentes circulaient, c'était l'eldorado. Certaines bousillaient l'image chunky source parce qu'elle s'en servait de tampon, d'autres faisait la moitié de la C2P au cpu, et les 2 derniers planes au blitter, avec des triples buffers pour essayer de paralléliser tout ça. (en général on est toujours en triple buffer pour d'autres raisons de synchro video)
Les c2p efficaces, ça a commencé a être celles qui écrivent des move.l (copie de 32bits) en chip, et font les opérations de changements de bits de la c2p avec les registres 68020, sans toucher la mémoire, entre 2 move.l.
Michael Kalms a été le plus fort à ce jeux, dés 1996 il proposait des c2p "copyspeed sur 060", sans buffer intermédiaires, et sans blitter.
vers la fin des années 90, il était toujours sur le channel irc "#amycoders" .. une fois il m'avait passé une archive qu'il avait faites, avec une vingtaine de c2p, adapté à tel ou telle conf amiga, pour tel ou tel besoin (résolution fixe, résolution qui change, ) bref un gros boulot.
Il doit encore avoir moyen de le tanner pour avoir ça, ça n'est pas sur aminet on dirait (mais il y a d'autres c2p sur aminet !).
A noter:
Si on est en 256 couleurs, on doit changer 8 bitplanes. Toute les c2p que j'ai vu font 2 boucles qui d'abord se charge des 4 premiers planes, puis des 4 derniers.
si on bride une c2p 256 couleurs vers 64 couleurs, on doit toujours garder le 2 boucles, et on est a peine plus rapide. Si on bride une c2p 256 couleurs vers 16 couleurs, là on est exactement 2 fois plus rapide.
... et puis sur ce genre de questions, le forum code de amiga demoscene archive est trés bien:
http://ada.untergrund.net/forum/index.php?action=vtopic&forum=4
