Re: LE BLITTER SUR ATARI ST

[Templeton]

Ah oui une arnaque commerciale c'est sans doute pour ça que mes parents ont jeté mon A500 il y a quelques années 

J'ai la mère d'un copain qui a jeté tous ses jeux Sega Master System qui étaient rangés dans un carton au fond du garage, elle pensait que c'était des vieilleries inutiles.
Je compatis à votre chagrin. 

Mcoder, le légendaire programmeur ST l'a dit sur le forum Atari,... un ST ne sera jamais aussi rapide qu'un Amiga.

Pas du tout et rocky007 a bien raison, dans de nombreux cas le ST est plus rapide. Ce n'est pas seulement lié à une différence de clock de +- 12%.
L'organisation mémoire hardware des Bitplans (différente par rapport à l'Amiga) permet d'utiliser des instructions 68000 différemment sur le ST.
Par exemple sur l'Atari le MOVEP.L peut accélérer certaines routines comme les "chunky To planar" (c2p), car il permet de remplacer 20% des instructions et mettre en cache 8 pixels dans un long mot. Pas sur Amiga.

Archer MacLean, le légendaire codeur de Dropzone et d'international Karaté avait révélé dans une interview que ses routines 3D dans Jimmy White's Snooker étaient environ 24% plus rapide sur ST que sur Amiga. 
Sachant que la vitesse supérieure du 68000 sur ST ne permet pas une telle différence, je suppose qu'il a utilisé la même technique que dans mon "polygone filler".

Idem pour les propos de Mcoder sur le Blitter VS 68000.

Tobe/MJJ Prod (l'un des pionniers du Blitter sur Atari), Templeton/CV (roohh le prétentieux ), et des légendes comme Anima/Light ou le génie Douglas Litle (DML / The Pixel Twins) ont prouvé que MCoder/The Starfires était complètement dans l’erreur concernant les capacités du Blitter.

Même le génial et légendaire Leonard/Oxygène a viré sa cuti et considère le blitter comme une super alternative au 68000 dans de nombreux cas maintenant.

Léonard est un ayatollah du 68000 (comme Mcoder), mais c'est aussi un pragmatique alors quand il a vu que son record de sprite de 32*32 (et celui de Mcoder) avait été battu par la routine au Blitter d'Anima il s'est décidé (enfin!) à l'utiliser.
Résultat, il adore cette puce maintenant et l'a utilisée massivement dans sa démo "We Were@".

Bref faut pas croire tout ce que raconte Mcoder, tout le monde peut se tromper... même les meilleurs!

Le Blitter est vraiment une puce sympa pour l'Amiga et le ST. Après si on compare les performances de transferts avec les débits cpu/mémoire de l'Archimedes, ces 2 Blitters sont absolument ridicules...

[Templeton]

En mots simples svp, comment fonctionne le Blitter du ST ? 

Le Blitter fonctionne en déplaçant des blocs mémoires, avec ou sans Opérations Logiques, d'un point A à un point B au bit près.
Il permet aussi d’oblitérer des zones dans la mémoire (effacement ou remplissage avec ou sans OP).

Il possède aussi certaines caractéristiques qui n'existent pas sur le Blitter de l'Amiga (l'inverse est aussi vrai) ou celui du Mindset (le premier ordinateur de l'histoire à être équipé d'un Blitter).

La plus notable est la présence d'une petite RAM (appelé Halftone RAM). C'est une RAM sans Wait State, donc tout ce qui transite par elle lors d'un transfert mémoire est 100% gratuit !
Je l'utilise souvent dans mes jeux et démo sur Mega ST/Ste/Falcon. 

Par exemple, c'est grâce à elle si je peux afficher le troisième Play Field (la pluie animée) dans certains niveaux du jeu Crash Time Plumber du DR Floyd. L'affichage de cette pluie est 100% gratuit!
Autre exemple, dans la démo Monogatari de Cérébral Vortex (La première démo hi-res Ste que j'ai réalisée avec Orion_), je l'utilise pour tramer les polygones HD afin de simuler un light source, ou pour réaliser le scrolling derrière les vecteur Balls.
Cette petite RAM je l'adore! MMMmmmm Smack ! 

Permet il des calculs plus rapides ?

Ce n'est pas vraiment un copro dédié au calculs même s'il peut réaliser des opérations booléennes.
Mais oui dans certaines configurations il permet des calculs plus rapides.
Par exemple, il excelle dans les calculs de décalage si la zone mémoire traitée est significative.
Il peut être détourné pour faire d'autre choses, comme retourner rapidement des zones mémoires sur l'axe des abscisses , réaliser des calculs de collisions au pixel près (merci Patrice Mandin), faire du fading en true color, ou augmenter le nombres de couleurs sur une ligne par exemple.

Un affichage plus rapide ? Les deux ?

Tout dépend de la taille de la zone mémoire que tu vas traiter. 

Un Blitter est lent à démarrer car il faut remplir  beaucoup de registres dont certains demandes des calculs.
Donc pour afficher certaines primitives graphiques comme des lignes obliques ou des Dots par exemple, il faut éviter le Blitter (même chose sur Amiga).

A contrario , pour afficher des "sprites", le Blitter est plus rapide lorsque la taille est égale ou supérieure à 32 pixels (largeur/Hauteur) en 4 bitplans.
Pour oblitérer de grosse quantité de mémoire, le Blitter est plus efficace également.

Dans certains cas, même si le résultat est plus lent qu'avec le 68000, il peut être intéressant d'utiliser le blitter pour économiser de la mémoire .

Le Blitter est il responsable (a lui seul) des probs de rétro-compatibilité entre certains softs STf et STe ?

Le Blitter n'est pas responsable, le problème de compatibilité Stf/Ste est majoritairement software et est lié aux routines de protection des programmes contre la copie ! 

Et sinon , pourquoi est il debrayable dans le menu du ST ? 

Je ne sais pas, peut-être pour montrer sa réelle efficacité par rapport aux affreuses routines VDI . 

Ou pour prévoir le retrait d'éventuels artefacts graphiques en cas de mauvaise programmation du blitter ? 

Ou alors peut-être qu'il est désactivable en cas d'installation d'une carte accélératrice qui rendrait la puce obsolète ?
D’ailleurs les routines de NVDI sont plus rapides que celles qui utilisent le Blitter...

[ArchieForEver]

Stapha à qui j'ai dû donner qq cours de rattrapages ?  et si pour toi +-12% de différence de clock ce n'est pas suffisamment important, faut revoir tes maths

Stapha est une burne, il n'est une référence que pour les tarés de l'Amiga.
Ce qu'il a raconté sur l'Archimedes est à se faire pipi dessus.

[k1200rs21]

sans parler  du taré de Archimedes 

[k1200rs21]

je me demande comment se site est modéré! il n'y a qu'ici que je trouve la modération si laxiste sur tout les sujets Amiga 
 quand on tape excessivement sur les posts Amiga sa passe, quand on tape sur les utilisateurs Amiga sa passe aussi   
avant de venir ici je n’ai jamais vu de post qui critique Archimedes car je m'en cogne et il est très bien, je ne vois pas ou il y a un problème avec Archimedes si ce n'est celui qui en parle ! 
dans 10 ans il y aura toujours la même discussion en boucle .
moi je vais continuer de vivre dans mon coin avec mon amiga sans aller cracher sur Archimedes et je me demande même si on a vraiment cracher sur lui en France !!! 
faut être maso pour aller chercher des info sur EAB quand on critique en plus le site!!!!
je dit vive Archimedes ,vive Amiga ,et vive Atari et il faut grandir on n'a plus 10ans

[dav1974]

"je dit vive Archimedes ,vive Amiga ,et vive Atari et il faut grandir on n'a plus 10ans"

 Va dire ça a Mimi mathy ....

[ArchieForEver]

sans parler  du taré de Archimedes 

LOL
La différence c'est que je sais de quoi je parle concenant la machine d'Acorn, et si je parle de ses points forts, je n'occulte pas ses points faibles ; à la différence des tarés ( <> utilisateurs ) de l'Amiga qui sortiront tous les mensonges possibles, les + grossiers qui soient, pour vanter de fausses caractéristiques de leur vénéré ordibouse.

Si je passe sur eab, c'est pour bien apprécier les limitations de l'Amiga, car sur ce site, malgré l'armée de débiles fanatiques de l'Amiga, incultes en programmation, ultra nuls à chier en 'technique' informatique, membres de la même secte que l'on peut également trouver sur Gamopat, et pour lesquels j'ai le plus haut mépris, il y a néanmoins des codeurs honnêtes qui expliquent très bien tout ce qui ne va pas dans l'Amiga, son architecture défaillante, les faibles capacités du chipset qui en font non seulement une piètre console de jeux, très difficile à programmer, mais aussi une bécane très lente inapte à être un bon ordi ( tant qu'on n'a pas ajouté une carte accélératrice de très bonne facture pour tout faire au CPU ... exactement comme un Archimedes, en somme )

[wulf]

Merci @Templeton pour tes réponses claires, précises et complètes !!

[Copper]

Ah oui une arnaque commerciale c'est sans doute pour ça que mes parents ont jeté mon A500 il y a quelques années 

J'ai la mère d'un copain qui a jeté tous ses jeux Sega Master System qui étaient rangés dans un carton au fond du garage, elle pensait que c'était des vieilleries inutiles.
Je compatis à votre chagrin. 

Merci c'est sympa bon ca fait longtemps maintenant. Mais heureusement ils n'ont pas jeté les disquettes mais j'avais du acheter une catwaesel pour pouvoir au moins récupérer les programmes (pourris) que j'avais fait à l'époque

[drfloyd]

Ah oui une arnaque commerciale c'est sans doute pour ça que mes parents ont jeté mon A500 il y a quelques années 

J'ai la mère d'un copain qui a jeté tous ses jeux Sega Master System qui étaient rangés dans un carton au fond du garage, elle pensait que c'était des vieilleries inutiles.
Je compatis à votre chagrin. 

moi ma mere a une epoque a jeté les 40 premiers n° de TILT, pensant que c'etait des vieux journaux pourris.... 

rien que le n°1 aujourd'hui doit coter 150eur....

[Orion_]

l'avantage du blitter aussi c'est le gain de mémoire, car faire aussi rapide au 68000 ça demande soit du préshifting, soit des routines généré, et tout ça prend beaucoup de mémoire multiplié par le nombre de sprites/tiles a afficher.

et le blitter sur falcon, il dépote plus que le 030 ?
j'ai pu récuperer un falcon a nouveau et je vais bientôt faire quelques test au blitter pour un projet de portage sur falcon stock, ça va optimiser sec pour essayer de faire un truc propre =)

en tout cas j'ai télécharger super zazai da, j'ai hate de tester cet impressionnante chose

[tophe38]

Le blitter sur le Falcon n'est pas le miracle espéré. Il va à peine plus vite que sur un STE. La faute à la mémoire, toujours à la même vitesse que sur un STE.
Atari n'a pas fait d'effort la dessus. Certainement une question de temps/argent ...
Après, oui, le blitter est une très bonne chose. Mais il aurait mieux fallut qu'il soit en standard, dès le STF.

[ArchieForEver]

l'avantage du blitter aussi c'est le gain de mémoire, car faire aussi rapide au 68000 ça demande soit du préshifting, soit des routines généré, et tout ça prend beaucoup de mémoire multiplié par le nombre de sprites/tiles a afficher.

Exact.
Je pense que la solution pour limiter le besoin de mémoire c'est d'avoir un moteur qui génère les sprites compilés à la demande, puisque dans un jeu on a rarement besoin de tous les sprites en même temps.
Le moteur génère un petit bout du code à chaque VBL, ou bien autant que possible en utilisant tous les cycles inutilisés par le CPU par VBL.
Les seuls sprites compilés en permanence en mémoire sont ceux utilisés en permanence ( personnage, armes principales etc ).
On aura donc 'juste' besoin :
- d'une copie du sprite ( éventuellement packé pour gain de place )
- du moteur
- d'un buffer mémoire pour y générer le sprite compilé
Quand on n'a plus besoin du sprite compilé, la zone mémoire qu'il occupait est libérée, et si plus tard on a à nouveau besoin d'afficher ce sprite, on relancera l'opération de génération ( la version sprite elle reste en permanence en mémoire )
- d'un 'défragmenteur' de mémoire pour le buffer mémoire car avec les créations / destructions de sprites compilés on risque de se retrouver très vite avec des zones mémoire non utilisées discontinues, il faut donc concaténer l'espace pris par les sprites compilés, pour avoir une zone buffer mémoire libre continue pour écrire les codes générés suivants.

Une question : avec le 68000 quel est le nombre d'octets maximum qui peut être lu à un endroit en mémoire et écrit à un autre, et quelle taille prend cette / ces instruction(s), et combien de cycles pour faire l'opération ?
J'imagine que ces données doivent être alignée sur une adresse multiple de 2, car le 68000 est un 16 bits au niveau des mots lus en mémoire, c'est bien ça ?
Et si on n'est pas aligné, ça lève une exception ?
Sur l'ARM on peut lire, puis écrire jusqu'à 52 octets ( alignés sur une adresse multiple de 4 ) avec 2 instructions de 4 octets chacune.
Exemple :
R13 adresse source
R14 adresse destination
LDMIA R13!,{R0-R12}
STMIA R14!,{R0-R12}
R13 et R14 sont auto incrémentés avec l'usage du '!'
Chaque instruction prend 15 ou 16 cycles
Les adresses source et destination n'ont pas besoin d'être alignées ( = multiple de 4 ), LDMIA et STMIA font automatiquement l'alignement en mettant à 0 les 2 bits de poids faible ( et ça ne prend aucun cycle supplémentaire ) le temps de s'exécuter.

[Templeton]

Le blitter sur le Falcon n'est pas le miracle espéré. Il va à peine plus vite que sur un STE. 

Pas du tout et c'est un miracle dans certains cas !

Le Blitter du Falcon est beaucoup plus rapide que celui du Mega ST sortit en 1986 (et donc du STe).
Sur Falcon il est cadencé à 16 mhz contre 8 mhz sur Mega ST/ STe. À cause de son implémentation sur le Bus il n'est pas 2 fois plus rapide mais presque(environ 90% plus rapide).

Quand je réalise un jeu sur Mega ST, j'essaie d'exploiter un peu le STe et je rajoute aussi des patchs dans mon code pour le rendre compatible sur Falcon.
Comme le Blitter du Falcon est largement plus rapide j'en ai profité pour rajouter l'énorme Zeplin sur le jeu Crash Time Plumber par exemple.

et le blitter sur falcon, il dépote plus que le 030 ?

Ça dépend de l'utilisation que tu en fais et de la taille du bloc que tu vas transférer. Par exemple il est beaucoup plus rapide de faire du Gouraud Shading avec le Blitter. 

Anima a des routines de Sprites au Blitter très rapide sur Falcon (bien + que les miennes).
Après tout dépend de la taille du Sprite. Une routine CPU aux petits oignons doit bien gifler le Blitter dans des cas moyens, le 68030 possède 2 caches et un Barrel Shifter quand même! 

Pour faire un Scrolling c'est très pratique.

j'ai pu récuperer un falcon a nouveau ...pour un projet de portage sur falcon stock, ça va optimiser sec pour essayer de faire un truc propre =)

Génial! *\o/* 

Si tu envisages de convertir Alice Sisters (J'adorais le voir sur le rapace), je peux te garantir que tu pourras le faire tourner en 50 FPS avec le parallaxe (même avec mes routines) ! 

Faire un dual Playfield sur Falcon c'est très facile avec le mode 8 bitplans. Pas besoin de masquage au cpu, il suffit de bien arranger sa palette. 
Je peux te faire un template si ça te branche (Dual Playfield + Sprite Blitter + Scroll Hard).

En tout cas ton jeu est super mignon et comme tu es super doué en Level Design je l’achèterai direct les yeux fermés ! 

en tout cas j'ai télécharger super zazai da, j'ai hate de tester cet impressionnante chose

Arf ! Ce n'est pas un jeu Falcon, mais je te conseille d'y jouer dessus car en le rendant compatible, j'ai rajouté des options ( 50/60 hz, CRT/VGA, Overscan On/Off, Musique Mp2, etc.)

Il va falloir que tu aiguises tes réflexes!

[tophe38]

Merci pour ton avis.
Le soucis, c'est que l'architecture du Falcon n'est malheureusement qu'un STE avec un 68030 à 16Mhz (toujours par soucis d'economie et de temps). Le reste, notamment la mémoire, reste à une fréquence plus basse. Hors, le blitter travaillant par copie de mémoire, il ne lui sert à rien d'aller plus vite.
De plus, dès que l'on met une petite accélération (genre, un centurbo 1), il faut le déactiver, sinon, ça glitch, voir, ça plante.

Pour info, certains semblent partager cet avis dans ce post sur Atari-Forum.

Sinon, je le répète, le blitter est un add-on indispensable. Je refuse d'utiliser un ST sans blitter

[Templeton]

Le soucis, c'est que l'architecture du Falcon n'est malheureusement qu'un STE avec un 68030 à 16Mhz 

Ça c'est faux.
Si c'était le cas, le Falcon n'aurait qu'une puissance de 5.76 MIPS or il développe une puissance de 21.76 MIPS!
Le Falcon est un ordinateur Bi-processeur, pas le STf/e, ce qui fait déjà une grosse différence. 
On ne résume pas l'architecture d'un micro seulement à son bus CPU/Mémoire, surtout quand il en a plusieurs différents....

Deuxième différence, le Videl n'a strictement rien à voir avec le Shifter. Non pas parce qu’il propose de nouveaux modes vidéo (entre autres) mais parce-que sa communication avec le BUS utilise une philosophie complètement différente du ST.

Troisième différence, le BUS entre la RAM vidéo et le VIDEL est en 32 BIT avec une fréquence beaucoup plus élevé.

Quatrième différence, certes le BUS de données est toujours 16 bits et le bus d'adresses 24 bits comme sur le STf/e, mais il est cadencé 2 fois plus vite.

Enfin tu sembles oublier une chose essentielle (qui n'existait pas sur la carte de développement)... La matrice d'interconnexion hardware dont l'heureux bénéficiaire est le DSP !
Grâce à cette matrice (entre autres) le DSP communique avec la mémoire vive, la puce sonore (le CODEC), le PSG, l'entrée micro, la sortie casque, le 68030, le connecteur DSP, etc...
À côté le 68030 donne "l'impression" de n'être qu'un copro... Le cerveau du Falcon c'est le DSP en réalité.

Le reste, notamment la mémoire, reste à une fréquence plus basse. Hors, le blitter travaillant par copie de mémoire, il ne lui sert à rien d'aller plus vite.
Pour info, certains semblent partager cet avis dans ce post sur Atari-Forum.

Sauf que l’intérêt du Blitter n'est pas de faire une copie de la mémoire, mais de la transformer!
Or il faut effectuer des calculs pour çà, donc plus ta fréquence est élevée et plus la transformation sera rapide.

Frank B ne fait qu'une simple copie dans son exemple... autant utiliser le 68030 !

Concernant le post sur Atari-Forum voici ce que dit ppera: 

We already stated in another thread that simple copy with blitter is not the for what it is designed, neither is good for speed comparison.
Try some more complex test - with shifts, masking etc.
Ratio will probably go over 4-5 in some cases (maybe not for shift, since 68030 is much faster in that than 68000).

Maintenant tu comprends pourquoi j'arrive à afficher beaucoup plus de choses avec le Blitter du Falcon.

Moralité, il faut utiliser le Blitter pour faire ce pour quoi il a été conçu.

Sinon, je le répète, le blitter est un add-on indispensable. Je refuse d'utiliser un ST sans blitter 

Tu prêches un converti.

[tophe38]

Encore un grand merci pour avoir pris le temps de détailler tout ça
Perso, j'avais bien joué avec le blitter, le scroll hardware sur mon STE (j'avais bien vu la différence avec le STF), mais le Falcon, je ne l'ai eut qu'après la fin d'Atari. Donc, je n'ai pas creusé la bête.
J'ai néanmoins toutes les docs papier existantes. J’espère avoir un jour le temps de m'y replonger.
Néanmoins, pour revenir sur le Blitter, il faudra que je regarde dans le TOS comment le Blitter accélère le GEM. Parce que son efficacité ne passe pas inaperçue.
Mais quand on voit ce que fait NVdi, je me dis l'API VDI d'Atari ne doit pas être très efficace.

[rocky007]

@Templeton un réel plaisir de te lire car tu maitrises vraiment le sujet et cela change du trolling habituel. J'ai lâchement abandonné Atari à l'époque du Falcon, j'en possède pourtant un, mais je ne m'y suis malheureusement jamais vraiment intéressé. j'ai pourtant suivi un peu les prods sur Falcon, mais je n'ai jamais vraiment vu qsq chose qui exploitant le quadruoo Videl-CPU-DSP-Blitter d'une façon incroyable. As-tu un exemple d'un jeu ou demo qui tirerait le maximum, à l'image de la We were @ du STe ?

[cryodav76]

merci des info comme quoi la réputation, je pensais également que le falcon n'était qu'un ste avec un 68030 + dsp .
il y a quelques demos qui utilisent le dsp pour la 3d d'ailleurs.

[Orion_]

@Templeton   un réel plaisir de te lire car tu maitrises vraiment le sujet et cela change du trolling habituel.  J'ai lâchement abandonné Atari à l'époque du Falcon, j'en possède pourtant un, mais je ne m'y suis malheureusement jamais vraiment intéressé.  j'ai pourtant  suivi un peu les prods sur Falcon, mais je n'ai jamais vraiment vu qsq chose qui exploitant le quadruoo Videl-CPU-DSP-Blitter d'une façon incroyable.  As-tu un exemple d'un jeu ou demo qui tirerait le maximum, à l'image de la We were @ du STe ?  

Une démo d'époque (95) qui montre bien la puissance du DSP avec un moteur 3D flat/gouraud vraiment chouette
https://www.youtube.com/watch?v=Ysr_qRcbs-o

et une démo d'aujourd'hui qui montre que le DSP du falcon, exploité par un dieu, ça donne du raytracing temps réel
https://www.youtube.com/watch?v=K9vUfsZ3eiY

[Orion_]

Une question : avec le 68000 quel est le nombre d'octets maximum qui peut être lu à un endroit en mémoire et écrit à un autre, et quelle taille prend cette / ces instruction(s), et combien de cycles pour faire l'opération ?

tu a l'opération "movem" qui est principalement utilisé pour charger / sauver des paramètres sur la pile (comme ldmia sur arm)
donc tout dépends des registres que tu souhaite garder ou pas, et aussi on ne peut pas stocker les données avec movem et incrémenter en même temps (vu que c'est une instruction prévu pour la pile, quand on stocke les données c'est forcement avec pré-décrementation) (ex: movem.l d0-d7,-(a7) )
donc une routine de copie donnera:

Code:

movem.l (A0)+,D0-D7/A2-A6
 movem.l D0-D7/A2-A6,(A1)
 movem.l (A0)+,D0-D7/A2-A6
 movem.l D0-D7/A2-A6,52(A1)

etc...

donc 52 octets d'un coup, après on peu gagner encore 4 octets si on met une adresse mémoire fixe au lieu du registre A1, et encore 4 octets si ont utilise A7 (la pile), par contre il faut désactiver les interruptions pour éviter que A7 soit utilisé

[cryodav76]

on dirait de l'amiga c'est dire!

[Orion_]

Si tu envisages de convertir Alice Sisters (J'adorais le voir sur le rapace), je peux te garantir que tu pourras le faire tourner en 50 FPS avec le parallaxe (même avec mes routines) ! 

Faire un dual Playfield sur Falcon c'est très facile avec le mode 8 bitplans. Pas besoin de masquage au cpu, il suffit de bien arranger sa palette. 
Je peux te faire un template si ça te branche (Dual Playfield + Sprite Blitter + Scroll Hard).

ayaaa tu lit dans mes pensées
je pense que c'est un beau challenge et effectivement un jeu très sympa a avoir sur le rapace :)

Comme c'est un jeu megadrive a la base, j'ai 4 palettes de 16 couleurs, une pour chaque playfield, et le reste pour les sprites, donc oui y'a moyen de bien optimiser par plan.
par contre pour le scroll hard j'ai encore du mal a comprendre comment faire, car pour faire boucler le buffer de gauche a droite, je vois pas, a part avoir 4 écrans, 2 pour le double buffering, et 2 en reserve ou on écrit les tiles en même temps que sur les 2 premiers buffer mais qui sont la pour swapper au moment ou on a dépasser la taille d'un écran et qu'on boucle. (faudrait un schéma parceque a expliquer c'est pas évident)
Après pour un dual playfield il faut carrement reblitter au moins le background a chaque fois

Pour Super Zazai, je parlais de la version STe bien sur, je suis impressionné car, pour mon jeu Escape 2042 j'ai déja bien taté du blitter et franchement j'ai galéré pour maintenir 50 fps en affichant quoi ... a peine 10 ou 15 sprites, alors quand je vois le nombre de choses qui bouge à l'écran de Super Zazai, je suis (bon certes, tu n'utilise qu'un plan pour les boulettes, mais quand même !)

[rocky007]

et une démo d'aujourd'hui qui montre que le DSP du falcon, exploité par un dieu, ça donne du raytracing temps réel
https://www.youtube.com/watch?v=K9vUfsZ3eiY

vraiment impressionnant

[Templeton]

Une démo d'époque (95) qui montre bien la puissance du DSP avec un moteur 3D flat/gouraud vraiment chouette
https://www.youtube.com/watch?v=Ysr_qRcbs-o

Pour l'anecdote le musicien a composé la musique sur Amiga avec protracker. 
Les trajectoires de la caméra dans le hangar et sur le circuit ont été enregistrées avec un joystick par ce même musicien (c'est un vrai moteur de jeu en temps réel).
Et ce dernier, qui était un pote de mon frangin, était venu emprunter notre Falcon030 pour synchroniser les images avec sa musique sur sa démo précédente (Are you Experienced?).

Imaginez plusieurs jours sans Falcon030 en 1994... c'est comme un monde sans AK-47... INSUPPORTABLE !

et une démo d'aujourd'hui qui montre que le DSP du falcon, exploité par un dieu, ça donne du raytracing temps réel Very Happy
https://www.youtube.com/watch?v=K9vUfsZ3eiY

Quand tu penses que ce Dieu du code a commencé sa carrière d'informaticien comme infographiste...

Pour Super Zazai, je parlais de la version STe bien sur, je suis impressionné car, pour mon jeu Escape 2042 j'ai déja bien taté du blitter et franchement j'ai galéré pour maintenir 50 fps en affichant quoi ... a peine 10 ou 15 sprites,
 alors quand je vois le nombre de choses qui bouge à l'écran de Super Zazai, je suis  (bon certes, tu n'utilise qu'un plan pour les boulettes, mais quand même !)

Le jeu gère 128 boulettes + 128 particules + un Starfield + une dizaine de monstres + un Hud + le joueur et ses 5 tirs sans ralentissements. C'était marrant à coder.
80% du taf est réalisé avec le 68000 et le reste au Blitter (Big boss, lune, 1 bit plan oblitéré, etc.)),il y aurai moyen de le faire tourner sur un simple ST mais j'ai trop la flemme....

par contre pour le scroll hard... et 2 en reserve ou on écrit les tiles en même temps que sur les 2 premiers buffer mais qui sont la pour swapper au moment ou on a dépasser la taille d'un écran et qu'on boucle. 

Oui c'est exactement la méthode que j'ai utilisée dans un vieux moteur sur STe.
Par contre pour uns scrolling 8 ways comme dans ton jeu tu devras réserver 4 buffers pour l'écran logique + 4 buffers pour l'écran physique, soit une occupation mémoire de 614,4 ko pour une réso de 320*240.

Il paraît qu'en reconfigurant le VIDEL à chaque trame où pourrait se passer du scroll hardware, tu n'aurais besoin que de 2 écrans un peu plus large et haut (proportionnel au nombre du pixel max déplacé par le scroll), et donc une occupation mémoire environ 4.5 fois moins grande.

Après pour un dual playfield il faut carrement reblitter au moins le background a chaque fois

Oui, pas certain qu'avec 40 sprites tout passe avec le Blitter dans la VBL.
Moi je pré-décalerai le background dans la mémoire et utiliserais le 68030 pour l'afficher, après tout, un peu plus de 600 ko ce n'est rien quand on a 4 Mo pour un jeu oldschool.

[Orion_]

je viens de faire un test avec la halftone, on peut masquer N plan de 16x16 pixels en une opération, avec 8 cycles par plan au lieu de 12 cycles si on utilise une source de donnée classique, tout ça en mettant en "cache" le masque de 16x16 pixels dans la halftone, c'est excellent ! pour un tilemap avec des tiles de 16x16 c'est juste parfais
je ne connais pas le timing en cycle du 68030 (y'a une table la dessus ?) mais a mon avis faire ça en moins de 8 cycles me parait peut jouable !

[rocky007]

petite question hors sujet, mais j'en profite que l'on parle du Falcon.... j'en possède un depuis une quinzaine n'année, et j'aimerais en récupérer un second pour au cas où le 1er tombe en panne.
J'ai un collectionneur qui possède 2 falcon 030, un en desktop avec lecteur CD, et un d'origine mint, et ce au même prix...sur le plan strictement valeur de la machine, laquelle des deux me conseillerez-vous ? je suppose que celui qui est d'origine garde plus de valeur qu'un desktop ?

[rocky007]

sinon pour revenir dans le sujet, on parle souvent de blitter pour le graphisme, mais a-t-il un avantage sur le CPU pour des opérations mathématique ( par exemple traiter une table de données, effets sur des samples ) ?

[Templeton]

je viens de faire un test avec la halftone...je ne connais pas le timing en cycle du 68030 (y'a une table la dessus ?) mais a mon avis faire ça en moins de 8 cycles me parait peut jouable !

je pense aussi.

Elle est géniale cette RAM (dommage qu'elle soit si petite), tout ce qui transite par elle est gratuit quand tu la combines avec la source principale.

Je ne sais pas si tu as vu, mais il y a 2 bits de contrôle dans un des registres du Blitter qui permet de choisir l'emplacement du départ dans la halftone.

J'ai remarqué aussi un truc, il vaut mieux stocker tes datas par colonnes plutôt que sur une ligne, passés 16 mots de large tu perds des cycles lors du transfert. 

J'ai un collectionneur qui possède 2 falcon 030, un en desktop avec lecteur CD, et un d'origine mint, et ce au même prix...
sur le plan strictement valeur de la machine, laquelle des deux me conseillerez-vous ? je suppose que celui qui est d'origine garde plus de valeur qu'un desktop ?

Oui tu supposes bien. Imagine un possesseur de Ferrari F40 qui change sa carrosserie par celle d'une Lada (parce-que c'est fun ), je doute qu'il puisse toujours la vendre 1,5 million d'euros. 
Moi je prendrai celui d'origine mint à moins que tu n'aies pas de lecteur CD, et puis si ton Falcon d'origine tombe en panne, tu pourras toujours permuter avec la carte du desktop. 

on parle souvent de blitter pour le graphisme, mais a-t-il un avantage sur le CPU pour des opérations mathématique ( par exemple traiter une table de données, effets sur des samples ) ?

À part les opérations booléennes et le shift, c'est très limité pour le calcul. 
Certaines choses non liées au graphisme sont possibles en tout cas, puisque Patrice Mandin a utilisé le Blitter pour faire des calculs de collisions au pixel près.

[tophe38]

Concernant la demande de Rocky007, même réponse de Templeton.
Même si je n'ai pas vu comment est le desktop, mais la machine n’étant pas prévu à l'origine pour être dans ce format, c'est généralement mal fait, et plutôt bidouillé.
Donc, en plus d'être moche, c'est aussi peu fiable dans le temps.
J'ai déjà eut un falcon comme ça, et franchement, c'était une horreur.

De mémoire, il a du exister un ou deux boitier dédiés Falcon pour supporter tout l'attirail d'extensions. Ils sont rare, et du coup, cela peu changer la donne.
Après, que ce soit un ST, un Falcon, un A500 ou A1200, ces machines ont un boitier qui leur est propre, qui est leur identité. Je trouve dommage de le changer.

[ArchieForEver]

Une question : avec le 68000 quel est le nombre d'octets maximum qui peut être lu à un endroit en mémoire et écrit à un autre, et quelle taille prend cette / ces instruction(s), et combien de cycles pour faire l'opération ?

tu a l'opération "movem" qui est principalement utilisé pour charger / sauver des paramètres sur la pile (comme ldmia sur arm)
donc tout dépends des registres que tu souhaite garder ou pas, et aussi on ne peut pas stocker les données avec movem et incrémenter en même temps (vu que c'est une instruction prévu pour la pile, quand on stocke les données c'est forcement avec pré-décrementation) (ex: movem.l d0-d7,-(a7) )
donc une routine de copie donnera:

Code:

movem.l (A0)+,D0-D7/A2-A6
 movem.l D0-D7/A2-A6,(A1)
 movem.l (A0)+,D0-D7/A2-A6
 movem.l D0-D7/A2-A6,52(A1)

etc...

donc 52 octets d'un coup, après on peu gagner encore 4 octets si on met une adresse mémoire fixe au lieu du registre A1, et encore 4 octets si ont utilise A7 (la pile), par contre il faut désactiver les interruptions pour éviter que A7 soit utilisé

Merci pour ta réponse.

Sur ARM par convention pour la pile telle que pointée par R13 par RISC OS on prendra plutôt stmfd et ldmfd mais bon ...
( Pour rappel il n'y a pas de registre dédié de pile, on peut créer sa propre pile. RISC OS lui utilise R13 comme pointeur de pile )

Combien de cycles au total pour ton code stp ?
Que se passe-t-il si A0 ou A1 ne sont pas alignés ?
Et quelle taille ces 4 instructions occupent-elles en mémoire au total ?

Sans vouloir vexer qui que ce soit on voit déjà que l'ARM est mieux pensé  ( plus souple ) pour les transferts mémoire que le 68000 ( et c'est logique, c'était un des buts recherchés dans la création de ce CPU ).