Quelques petites remarques simples qui pourraient te faire gagner à la fois du CPU et de la place.
Je vois que pour la palette tu fais pas mal de boucles avec A allant de 0 à 16. Du coup tu as toujours un CMPA #16 qui traine. Si tu démarrais ta boucle avec A=16 que tu décrois (DECA), tu n'a pas besoin de CMP #0 car elle est implicite avec le DECA qui peut être immédiatement suivi d'un BNE. D'une façon générale, en ASM on aime bien décompter plutôt que compter à cause de ca.
Dans le même ordre d'idée (la détection à 0 implicite), pour le joystick je te vois faire CMPA #1 + LBEQ right, puis CMPA #2 + LBEQ left, puis #3 top, et #4 bottom. Tu peux gagner des cycles et de la place en faisant juste DECA + LBEQ right, puis DECA + LBEQ left, DECA + LBEQ top, DECA + LBEQ bottom. Mais en fait, ici tu peux carrément faire beaucoup mieux que tout ca en utilisant une table de saut:
Code:
LDX #dir_tab
LDA player_dir ; A=0 .. 4
LSLA ; il faut 2 octets par adresse, donc on double A ici
JMP [A,X] ; on saute directement à joy_XXX ou afterPDIRtest suivant la valeur de player_dir
dir_tab
FDB afterPDIRtest ; A==0
FDB joy_right ; A==1
FDB joy_left ; A==2
FDB joy_top ; A==3
FDB joy_bottom ; A==4
afterPDIRtest
...
Ensuite dans ta macro PALETTE, je vois CLRA suivi de LDA #\0. Ce CLRA est inutile (le LDA écrase le 0 du CLR). Ensuite ce LDA #\0 est suivi par un ASLA. Or tu peux faire LDA #2*\0 qui combine les deux et te fais gagner 1 instruction (c'est l'avantage des macro aussi que de pouvoir laisser les calculs constants être faits lors de la compilation).
Par contre attention avec les macros, leur répétition mange très vite de la place. Parfois il vaut mieux passer par un appel de procédure. Je vais te montrer un truc que j'ai pas mal utilisé dans les intros de 1Ko à savoir MACRO + méthode + param dans le code le tout saupoudré de modification du compteur programme. C'est très pratique quand on a beaucoup d'appel à la même macro mais avec des paramètre constants mais différents d'un endroit à l'autre du programme:
Code:
MACRO PALETTE ; n=\0, valeur_palette=\1
JSR setPAL
FCB 2*\0 ; on laisse le compilateur faire la multiplciation par deux pour nous.
FDB \1 ; valeur palette (16 bits).
ENDM
* ceci ne figure a un seul endroit du code, donc c'est factorisé au maximum
setPAL
PSHS D,X ; on sauve les registres utilisés
LDX 4,S ; X pointe sur l'adresse de retour, c'est à dire ici le FCB avec 2*n
LDA ,X+ ; chargement de 2*n puisque X pointe dessus. A la sortie X pointe sur le FDB.
STA $E7DB ; mise à jour de l'indexe palette.
LDD ,X++ ; chargement de la valeur palette. A la sortie X pointe sur l'instruction suivant le FDB
STB $E7DA ; poids faible
STA $E7DA ; poids fort
STX 4,S ; on met à jour le PC de retour avec l'adresse de l'instruction suivante le FDB
PULS D,X,PC ; on récupère les valeurs des registres + le PC à jour
dans le code tu aura des
Code:
PALETTE 0,4095
PALETTE 2,123
comme avant, mais ce sera étendu en un code super conpact où le JSR est suivi par les valeurs attendues. Le code de setPAL se chargeant de mette à jour le PC à la sortie pour sauter par dessus les constantes (cela nécessite un peu de temps pour comprendre le truc, mais ca vaut le coup)
Plus loin dans le splash-screen je vois des STA ,Y suivi par LEAY 1,Y. Pourquoi ne fais tu pas directement STA ,Y+ ? Par ailleurs pour aller plus vite, le LDD/STD est plus rapide que de faire 2x plus de LDA/STA.
Plus loin encore je vois plein de code répétitif sur blinky (en fait sur tous les autres aussi):
Code:
p_set_anim_blinky_r
LDX #blinky_r_anim
STX blinky_anim
LBRA setanimblinkyend
p_set_anim_blinky_b
LDX #blinky_b_anim
STX blinky_anim
LBRA setanimblinkyend
p_set_anim_blinky_l
LDX #blinky_l_anim
STX blinky_anim
LBRA setanimblinkyend
p_set_anim_blinky_t
LDX #blinky_t_anim
STX blinky_anim
LBRA setanimblinkyend
p_set_anim_blinky_blue
LDX #blinky_blue_anim
STX blinky_anim
LBRA setanimblinkyend
p_set_anim_blinky_grey
LDX #blinky_grey_anim
STX blinky_anim
LBRA setanimblinkyend
p_set_anim_blinky_eyes
LDX #blinky_eyes_anim
STX blinky_anim
LBRA setanimblinkyend
* pinky ------------
...
setanimblinkyStart * set blinky anim
LDA blinky_set_num
CMPA #0 ;RIGHT
LBEQ p_set_anim_blinky_r
CMPA #1 ;LEFT
LBEQ p_set_anim_blinky_l
CMPA #2 ;UP
LBEQ p_set_anim_blinky_t
CMPA #3 ;DOWN
LBEQ p_set_anim_blinky_b
CMPA #4 ;set blue
LBEQ p_set_anim_blinky_blue
CMPA #5 ;set grey
LBEQ p_set_anim_blinky_grey
CMPA #6 ;set eyes
LBEQ p_set_anim_blinky_eyes ;//TODO sprite address
setanimblinkyend
RTS
Or tu pourrais factoriser bien plus et gagner pas mal d'octets:
Code:
p_set_anim_blinky_r
LDX #blinky_r_anim
bra p_set_anim_blinky
p_set_anim_blinky_b
LDX #blinky_b_anim
bra p_set_anim_blinky
p_set_anim_blinky_l
LDX #blinky_l_anim
bra p_set_anim_blinky
p_set_anim_blinky_t
LDX #blinky_t_anim
bra p_set_anim_blinky
p_set_anim_blinky_grey
LDX #blinky_grey_anim
bra p_set_anim_blinky
p_set_anim_blinky_eyes
LDX #blinky_eyes_anim
p_set_anim_blinky ; <==== point de rencontre qui factorise tous les STX/LBRA d'avant
STX blinky_anim
LBRA setanimblinkyend
Mais là encore on peut faire bien mieux sachant que blink_set_num va de 0 à 6 avec un table de valeur avec
Code:
setanimblinkyStart * set blinky anim
LDA blinky_set_num
LSLA
LDX #setanimblinkytab
LDX A,X
STX blinky_anim
setanimblinkyend
RTS
setanimblinkytab
FDB blinky_r_anim
FDB blinky_b_anim
FDB blinky_l_anim
FDB blinky_t_anim
FDB blinky_grey_anim
FDB blinky_eyes_anim
15 lignes au lieu de 40+. Qu'en dis tu ?
Bon ca fait pas mal de remarques à digérer. Je vais m'arreter là, mais sache que tu peux, en utilisant un approche plus généraliste (avec tableaux) réduire ton code, le rendre plus maintenable (car un gros code comme ca d'un bloc est vraiment gros pour garder sa structure en tête), et même possiblement l'accélérer (accéder à la case n d'un tableau est plus rapide que de faire pleins de cmp pour tomber sur le bon "n").