Fredifredo (./29) :je ne suis pas aller plus loin, car par la suite j'ai exploré d'autres contrées électroniques... et depuis peu je fais des travaux nettement plus manuels (rénovation de l'appart).
Des nouvelles de tout ça ?
Fredifredo (./29) :je ne suis pas aller plus loin, car par la suite j'ai exploré d'autres contrées électroniques... et depuis peu je fais des travaux nettement plus manuels (rénovation de l'appart).
Des nouvelles de tout ça ?
RYGAR (./32) :
On veut voir !
RYGAR (./35) :j'ai effectivement une petite idée derrière la tête. ^_^
Ah oui quand même ! Bon boulot !
Je trouvais cela un peu dommage de mettre de l'énergie et du temps pour refaire un jeu déjà existant sur Lynx mais ta version ce différencie vraiment du jeu Ms Pac Man et de ce fait justifie beaucoup mieux son intérêt.
C'est quoi le gros fantôme que l'on voit dans l'intro ? Tu comptes ajouter un "super gost" dans le jeu ?
Fadest (./7) :Merci Fadest, j'ai enfin compris comment faire une déclaration multiple de sprites. Je met ici les sources avec lesquels j'ai travaillé, 56 sprites d'une taille de 24x24 pixels pour afficher le décors + un long scrolling horizontal + zoom et dézoom d'un sprite lié mais n'impactant pas tout les autres.
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).
Pour répondre à Tempi, la Lynx est une telle bête en manipulation de sprites que c'est aussi simple de déclarer les gommes en sprites, plutôt que de jouer directement sur la mémoire vidéo, contrairement au ST par exemple. En tous cas, c'est ce que j'avais fait pour Ladybug (mais bon, 24h pour un clone de pac-man avec des portes qui tournent en plus, ça laisse peu de temps à la réflexion, hormis pour les portes qui tournent bien sur)
)
char SCREEN[8160] at (MEMTOP-16320);
char RENDER[8160] at (MEMTOP-8160);
SetBuffers(SCREEN, RENDER ,0);
beauregard (./47) :
Comme faire un flip de sprite on perd la couleur transparente, j'ai décidé de doubler le nombre d'image pour le glouton (dans les 4 directions). Une fois fait, j'étais satisfait, mais une ligne de 12 pixels de long est entre temps apparu, remplit de pixels aux couleurs changeantes: un bug ! Et je dirai même plus, un méchant bug.
Puis l'illumination, je me suis souvenu d'un second SetBuffers dans le code, indispensable lorsque l'on fait de la déclaration multiple de sprites.
SetBuffers(BUFFER1,0,0);
Je change la valeur, le bug se déplace à l'écran, chouette ! à 9300, il n'apparait plus, cool.
SetBuffers(0x9300,0,0);
Sur megadrive il y a l'émulateur regen avec lequel on peut voir la place de chaque image stockée dans la mémoire vive du copro VDP, mais avec la lynx j'avance dans l'obscurité...
Fadest (./51) :33,4 Ko actuellement, je n'avais rien fait d'extraordinaire, hormis la déclaration multiple de sprites, et cette dernière nécessite un bon usage du setbuffers, cela a fait tilt.
Bizarre ton truc sur la transparence, je m'en suis déjà servi…
Pour le glitch, quand ça me faisait ça, de mémoire, c'était que mon.o était trop gros et le signe d'une corruption RAM.
/// on a besoin de stdlib pour bcopy() de mémoire
#include <stdlib.h>
// SCB est un tableau de 113 sprites de 11 octets chacun
extern char SCB[112][11] at (0xfff8-16320-112*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