Après quelques mois de réflexion, je reprend...
Samuel Devulder a écrit:
Hihi je peux faire encore plus rapide en traitant 4 pixels d'uns coup (dans la même banque video)
Code:
LDD ,X ; (5) Lecture 2 octets de sprites en une fois
LDA A,U ; (5) Recup du masque pour le 1er octet
LDB B,U ; (5) Idem pour le 2nd octet
ANDA ,Y ; (4) Masquage depuis la vidéo (1er octet)
ANDB 1,Y ; (5) Idem avec 2n octet, donc D contient la vidéo où on a des "0" pour les couleurs non transparantes
ADDD ,X++ ; (9) Ajout des couleurs non transparentes pour le 1er et 2nd octet en une fois
STD ,Y++ ; (8) Mise à jour en ram vidéo des 1er et 2nd octets en une fois et avancée de 2 colonnes
J'avoue que c'est brillantissime!!
Et je suis honteux de ne pas avoir trouvé ça moi même, et c'est plutôt embêtant, si j'inclue ce code dans le jeu Bubble Bobble, je serai obligé de te mettre en auteur principal, tu fais tout à ma place!! Je voulais vraiment pondre un jeu moi même de A à Z... Y compris les optim algorithmique... Cependant, cette optimisation est partie de tests avec des NOT et AND que j'avais écrit au départ en BASIC... C'est fou ce que tu as tout optimisé...
Là on passe de 32-39 cycles de transparence (mon code) pour 2 pxl à 33 (j'enlève la dernière ligne, puisque je ne l'ai pas compté dans la partie "transparence" pour le calcul de mon algo, on ne parle ici que de la partie purement "transparence") pour 4 pxl. Autrement dit tu a divisé par 2 le temps d'exécution sur cette partie!
Le hic est que ça demande que le sprite fasse au moins 8 pxl de large (RAMA et RAMB) pour ce qui est des sprites genre missiles ou même des petites balles...
Nous donne tu l'autorisation d'utiliser cet algorithme ?
Samuel Devulder a écrit:
soit 5+5+5+4+5+9+8 = 41 cycles pour 4 pixels, au lieu de 2x29=58 si on travaille octet par octet avec le code juste au dessus. Le truc cool aussi c'est qu'on peut se permettre d'entrelacer le passage RAMA/RAMB si on ne supporte pas de voir à l'écran l'
effet de peigne quand on attends trop entre le passage RAMA/RAMB:
Code:
LDD ,X ; (5) lecture data sprite RAMA/RAMB en une fois
LDA A,U ; (5) Recup du masque pour RAMA
LDB B,U ; (5) Recup du masque pour RAMB
ANDA ,Y ; (4) Masquage pixels RAMA
DEC <$E7C3 ; (6) Passage sur l'autre page video (utilisation mode DP)
ANDB ,Y ; (4) Masquage pixels RAMB
ADDD ,X++ ; (9) Supperposition du sprite RAMA/RAMB en une fois
STB ,Y ; (4) Mise à jour écran RAMB
INC <$E7C3 ; (6) Retour en page RAMA
STA ,Y+ ; (6) Ecriture écran RAMA et avancée d'une colonne
5+5+5+4+6+4+9+4+6+6 = 54 cycles pour RAMA et RAMB dans la foulée là où le code d'origine nécessitait 2 passes de 44 cycles chacune.
Mon code d'origine, sans les masques, faisait entre 29 et 35 pour 2 pxl (si on utilise les accès RAM en mode direct).
Par contre je ne vais pas choisir ce code là, d'une part parce que c'est moins optimal, de plus, j'utilise le gate array pour 'laffichjage (et pas le E7C3, sauf pour ce qui va servir de tampon d'image de fond,, finalement, c'est l'espace $4000-$5FFF que j'utilise pour ceci
Vu que je n'ai pas envie d'utiliser l'espace cartouche afin d'accéder aux routine du moniteurs et extramoniteurs, et je crains que
le changement dans l'espace cartouche ne permette plus d'y accéder ?