1

Salut,

Il est tard, j'ai les yeux rougis, et je tape sur mon smartphone ce message qui est un témoignage, peut être le dernier.

Alors, j'ai décidé de reprendre un vieux programme, et de l'optimiser avec la fameuse déclaration multiple de sprites. Ça permet d'économiser vachement de mémoire, mais il y a un inconvénient : le compilateur accepte moins de lignes de code.
mur
Je me souviens alors, d'une déclaration de Fadest je crois, sur la longueur du code plutôt limité. Ben voilà, maintenant je comprend, alors deux possibilités : soit cette déclaration n'est pas bien digéré par la lynx, elle est donc à revoir, soit les outils sont bridés. Dans les deux cas cela nous interdit de faire un jeu complexe.

Je suspecte donc une entrave dans ce kit de dev, quelques lignes de codes anodines, et voilà le .o qui grossit à vue d'oeil... dommage. Si un programmeur doué dans l'utilisation d'outils de désassembleur hexa me lis, je suis sûr que nos .o sont remplis de vide, ou de série de 11111111 mis là à l'insu de notre plein gré.

Bien à vous les jeunes.

avatar
Travaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

2

Pas compris la ...
Au passage tu veux dire quoi par "declaration multiple" ?

3

Maeel (./2) :
Pas compris la ...
Au passage tu veux dire quoi par "declaration multiple" ?

là:
Fadest (./7) :
Pas vraiment un exemple, ni un tutorial, mais avec ça, tu devrais pouvoir t'y retrouver :

Pour la partie inits, il te faut déclarer les éléments suivants et la fonction init_sprites()/// on a besoin de stdlib pour bcopy() de mémoire #include <stdlib.h> // SCB est un tableau de 26 sprites de 11 octets chacun extern char SCB[25][11] at (0xfff8-16320-25*11); // spr0 est le "modèle" de sprite de 11 octet pour initialiser une occurence de SCB2[] extern char spr0[11]; // init_scb est le premier sprite à afficher, en fait, il pointe sur un sprite vide // j'aurais aussi pu le faire pointer vers le background // l'important dans le _init_scb, c'est dc.w _SCB2 // qui fait pointer le sprite suivant vers le premier du tableau SCB extern char init_scb[23]; #asm ; init_scb est utilisé pour initialiser les registres du SpriteEngine ; avec les paramètres adéquats (palette...) ; Using this trick, the 8*11 spr[]-SCBs only need 11 Bytes each! _init_scb: dc.b $c1, $10, $20 dc.w _SCB ; PTR_NEXT pointe vers le 1° sprite visible (SCB[0]) dc.w dummy ; PTR_DATA pointe vers un sprite "inexistant" dc.w 200, 200 ; x,y -> on affiche en dehors de l'écran dc.w $100, $100 ; pas de zoom dc.b $01, $23, $45, $67, $89, $ab, $cd, $ef dummy: dc.b 0,0,0 ; le sprite "inexistant" ; spr0 sert de modèle au sprites du tableau SCB _spr0: dc.b $c4, $08, $02 ; CTL0, CTL1 = réutilise la palette, COLL dc.w 0, 0 dc.w 0, 0 #endasm void init_sprites() { char i1; for (i1 = 0; i1 < 25; i1++) { bcopy(&spr0[0], &SCB[i1][0], 11); SCBX(&SCB[i1][0]) = 0; SCBY(&SCB[i1][0]) = 0; SCBNEXT(&SCB[i1][0]) = &SCB[i1+1][0]; } SCBNEXT(&SCB[24][0]) = 0; }

Le gros avantage d'utiliser une structure de 11 octets pour les sprites chainés, c'est de gagner 12 octets par sprite (ça peut gratter 1 ou 2ko au final, ce n'est pas rien), et également, c'est un peu plus rapide car le système sait que chaque sprite a les mêmes paramètres (zoom, tilt...).
Inconvénient, tu ne peux pas en zoomé un individuellement. Avantage, si tu zoomes le premier, tous le seront (ça peut être utile dans certaines circonstances)

Pour la suite, c'est facile, à un moment, tu appelles init_sprites pour initialiser ton tableau, ensuite, pour accéder individuellement à un sprite dans ton tableau :
SCBX(&SCB[ij][0]) = x; SCBY(&SCB[ij][0]) = y; // [...]


Un petit truc en passant, si tu ne veux plus afficher un sprite, tu peux soit le déplacer en dehors de l'espace écran, ou jouer sur SCBCTL1(]) pour le déclarer affichable ou non (il est initialisé à 8, mais si tu le mets à 12, ton sprite n'est plus affiché, ça accélère un peu le process).

avatar
Travaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx

4

Oh ok sprites chaines.
Je n'ai jamais utilise BLL mais je doute fortement que le grossissement de ton .o soit connecte a l'utilisation des sprites chaines ...

5

C'est pas déconnant, vu que les déclarations sont faites dans des tableaux, ton .o inclut donc en plus les 25*11 octets de la déclaration du tableau.
Si tu ne veux pas cet effet de bord, tu peux être courageux et utiliser de l'allocation mémoire dynamique, pour peu que els fonctions existent dans le kit BLL et surtout qu'elles soient fiables, mais ça reviendra au même, tu consommeras de la RAM, il faudra donc prévoir d'en laisser libre une fois ton programme chargé.

Donc non, il n'y a pas de bridage conscient dans les outils pour empécher les gens de bosser. Les outils ne sont peut-être pas parfait, avec pleins de trucs bizarres, mais c'est pas fait exprès roll
avatar
De nouveaux jeux pour vos vieilles consoles ? En 2024 ?
https://yastuna-games.com

6

Fadest (./5) :
C'est pas déconnant, vu que les déclarations sont faites dans des tableaux, ton .o inclut donc en plus les 25*11 octets de la déclaration du tableau.
Si tu ne veux pas cet effet de bord, tu peux être courageux et utiliser de l'allocation mémoire dynamique, pour peu que els fonctions existent dans le kit BLL et surtout qu'elles soient fiables, mais ça reviendra au même, tu consommeras de la RAM, il faudra donc prévoir d'en laisser libre une fois ton programme chargé.

Donc non, il n'y a pas de bridage conscient dans les outils pour empécher les gens de bosser. Les outils ne sont peut-être pas parfait, avec pleins de trucs bizarres, mais c'est pas fait exprès roll


J'ai terminé la conversion en sprites chainés.
pam
gain: une économie de 3,53 Ko (j'ai optimisé de ci delà, donc le gain réel avec le chainage est en réalité moins important).
tableau: passage de 16320 à 20400, car sinon il y a de gros soucis d'affichage (j'ai rajouté au pif 4080 (16320+4080 = 20400) afin que tout s'affiche correctement).
malus: je ne pourrai pas rajouter énormément de ligne, encore que le compilo doit avoir une limite en nombre de caractère. // SCB est un tableau de 63 sprites de 11 octets chacun extern char SCB[62][11] at (0xfff8-20400-62*11);

Conclusion: il y a du pifomètre + limitation codage = galère
fouet
avatar
Travaux, concept of proof, divers :
Megadrive
topics/172-143753-moved-juju-densetsu
Lynx
sections/255-developpeurs-lynx