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.
D'ailleurs je ne suis pas sûr de bien maitriser la méthode, j'ai l'impression que j'ai crée beaucoup plus de sprites que le pense !
113 sprites:
/// 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
up: Voici une petite video, commenté, sur le jeu testé sur la console:
[flash]http://www.mirari.fr/module/file/player/player_flv_maxi.swf?showfullscreen=1&showloading=1&showstop=1&showtime=1&flv=http://www.mirari.fr/owmD?a=open[/flash]