Voilà, j'ai fini de taper (aussi fidèlement que possible) le listing "SPRITES" d'Amstrad 100% n°47,
routine crée par Pict, membre du groupe de demo-makers LOGON SYSTEM.

L'archive .dsk est ici : http://dl.free.fr/gd0hahUL7

- sprtsrc.bin est le listing assembleur des pages 19,20 et 21 au complet.

- sprite.bas est le listing basic contenant les data.

Pour charger le code source dans DAMS : G, sprtsrc
Pour le lire : taper L entrée

Si il y a un courageux parmi vous pour regarder le listing et m'aider à déceler d'éventuelles fautes de frappes, merci.

Je vois 2 erreurs possibles commises par le magazine :

- Le "XOR a" (à moitié effacé, mais il apparaît donc je l'ai reproduit) en bas de la page 19 se retrouve
à nouveau au début de la page 20. Comme 2 Xor à la suite s'annulent, j'ai un doute. mauvais découpage ?

La 2ème erreur (que j'ai reproduite aussi, pour l'instant) se trouve à la fin du listing assembleur, page 21 :

- le label "nxtline" et les 3 lignes qui le suivent se retrouve 2 fois!!

On sait qu'en assembleur, il est interdit d'utiliser 2 fois le même nom pour un label,
sinon, comment voulez-vous qu'à l'assemblage, le programme puisse attribuer une adresse mémoire à nxtline ?

Voilà, il reste donc un peu de débogage à faire, puis à dessiner un sprite et à écrire quelques lignes d'assembleur
pour le faire bouger à l'écran et faire revivre les routines d'Emmanuel!

Je compte bien utiliser ce listing et ne pas le laisser dormir dans une archive.

Bon dimanche à tous, je sors faire un peu de VTT. (on s'en fout, je sais. c'était pour la chute.)

je pense qu'il s'agit d'erreurs dans la mise en page.. en tout cas merci de nous faire partager ton taf!

Merci pour ton scan surtout, qui m'a grandement facilité la frappe et à ceux qui ont donné des conseils.

Question de béotien en matière de dev sur 8bits :

Mais une routine de sprite asm qui se contente d'afficher une matrice x-y , en sautant les pixels de "fond" comme la couleur noire par exemple.
Bien entendu , la zone ou le sprite est affichée est sauvegardée dans un buffer et rétablie lorsque le sprite se déplace.
Cela prends trop de temps machine/mémoire ??c'est quoi le problème avec le dual field ?!?

c'est pas lié au 8-bit mais plutôt à la structuration de la mémoire vidéo (qui est affiché par le proc graphique) : chunky ou planar, là est plutôt la difficulté !

Ya pas de proc graphique sur cpc (à ma connaissance) , le crtc n'étant pas un processeur graphique en soit. Pour le reste ce que j'en sais, il n'y a pas non plus de mémoire vidéo dédiée à l'écran.
Par contre je ne sais pas si il est possible de faire une sorte de mode-x comme pour la carte vga sur pc.
Je cite de la bible du cpc :
"
Par programmation adéquate des registres 12 et 13 du 6845, l'écran peut commencer pratiquement en n'importe quelle case mémoire paire de la Ram vidéo"
Mais est-ce une ram spécifique à la vidéo ou juste une portion des 64k des 128k ? je crois que c'est juste ça..un peu comme sur l'atari st qui partage ses 512k avec la ram vidéo.

Après la façon qu'a d'adresser un pixel en ram vidéo le crtc , il suffit de programmer une routine qui le fait de façon générique et tu n'as plus à t'en occuper.

En gros l'idée c'est de faire du page-flipping sur des zones directement adressable par le crtc, sans recopier le buffer dans la ram vidéo

Mais je suppose que ca devait être fait depuis longtemps

Tu peux utiliser uniquement les 64 k de ram centrale comme mémoire vidéo, qui sont lues par le crtc


Ca s'appelle le "split screen" (ou rupture francisé).
Mais tu peux changer l'adresse vidéo (en général sauf "exceptions") uniquement au début d'un nouvel écran au sens crtc. Donc très difficilement applicable pour des "sprites"