Mon affichage de sprite a moi (ASM) - Page 4

En tout cas ca vaut le coup d'essayer.

Je connais pas mal de developpeurs qui ont essayé puis laché prise a cause de mauvaises perfs ou de maux de tete, mais c'est possible et ca marche bien.

La partie la plus tordue a coder est bien sur le clipping... Surtout a gauche.

Quelqu'un peut juste ouvrir une parenthese pour expliquer à quelqu'un comme moi ce qu'est exactement le RLE, j'ai lu tous les posts de ce sujet.. mais en fait je crois que c'etait trop d'un coup et donc je memmele les pedales lol

RLE signifie en anglais RUN LENGHT ENCODING, en gros on code une image sous la forme de "RUNs" de longeur variable, c'est souvent utilisé par exemple pour de la compression 1 bit (noir et blanc) tres rapide a decompresser.

Exemple : j'ai une ligne qui contient 12 pixels blancs, 3 pixels noirs, 18 pixels blancs et ainsi de suite

Je peux coder ca comme ca : un markeur pour dire la couleur (un bit suffit), et la longeur de mon "RUN".

Maintenant quel interet pour l'affichage de sprites ?

Comme on parle bien de sprite et non de tiles, on suppose que de nombreux pixels seront transparents, sans RLE on doit tester chaque pixel avant de decider de l'afficher ou non, et on ne peut afficher qu'un pixel a la fois car le suivant est peut etre transparent.

Avec un encodage de type RLE on saute les "RUN" transparent, et on affiche jusqu'a 16pixels d'un coup quand c'est possible (c'est souvent possible), ca evite bcp de tests, ca reduit l'encombrement du sprite (donc meilleur usage de la memoire et donc du cache), et ca permet egalement d'autres tricks comme le prefetch du cache...

Ah ben ma fonction d'affichage elle fait à peu pres ça.. En fait c'est comme rov (je copie une suite de pixels, je saute, je copie, je saute etc.. j'ai aussi un tableau jump, un tableau pour les pixels non transparents (donc pour ce qu'il y a entre les differents jump) etc..). mais je ne sais pas à quelle vitesse elle va, comment on peut tester ça ?

Le format flux n'est en effet pas obligatoire, c'est pourtant celui qui me semble le plus adapté...

Mais il faudait en voir plus sur ton implementation pour faire des estimations sur son efficacité, sinon tu peux tjrs bencher.

Par exemple afficher des sprites juqu'au vblank, et compter le nombre de sprites affiché en une frame....

Vu qu'il n'y a pas de fonction de timer precis sur GP32..

JyCet :
Ah donc ça s'appelle du RLE ce que j'essayais de faire
Bon ben maintenant je sais que ma fonction RLE marchait pas

Allez, on y croit. Deja t'avais choisi quoi comme convention pour ton encodage RLE ?
un octet pour le nombre de case a sauter, un octet pour la couleur du pixel d'apres ? Ou un truc plus fute ? (parce que comme ca si t'as plein de pixels de couleur differente qui se suivent, c'est moyen, t'as plein de "sauter 0 pixels" a lire)

------------------------------------------------------------------------
// test fast sprite
//unsigned int tbl_sprINTRO_w[216];
//unsigned int tbl_sprINTRO_x[216];
//const unsigned char spr_INTRO[34560];
/* unsigned char countx,county,flag=0;
for (i=0;i<216;++i){
tbl_sprINTRO_x[i]=0;
spr_temp[i]=0;
tbl_sprINTRO_w[i]=0;
}
for (i=0;i<34560;++i){
if(spr_INTRO[i] != 0xff){
if (flag==0) tbl_sprINTRO_x[county]=countx;
spr_temp[county]=1+countx;
flag=1;
}
++countx;
if (countx==160){
++county;
countx=0;
flag=0;
}
}
for (i=0;i<216;++i)
tbl_sprINTRO_w[i]=spr_temp[i]-tbl_sprINTRO_x[i];
*/
------------------------------------------------------------------------------------------
void gp_fastsprite(unsigned char * sprite, u8 trans , short spr_x, short spr_y, short size_x, short lcd_x, short lcd_y)
{
GpTransBlt(NULL,&gpDraw[nflip],lcd_x,lcd_y,size_x,1,(unsigned char*)sprite,spr_x,spr_y,160,216,trans);
}
------------------------------------------------------------------------------------------

//gp_fastsprite(unsigned char * sprite, u8 trans , short spr_x, short spr_y, short size_x, short lcd_x, short lcd_y)
/* for (i=0;i<216;++i)
//if (tbl_sprINTRO_w[i])
GpTransBlt(NULL,&gpDraw[nflip],
y+tbl_sprINTRO_x[i],5+i,tbl_sprINTRO_w[i],1,(unsigned char*)spr_INTRO,tbl_sprINTRO_x[i],i,160,216,255);
*/ /*
gp_fastsprite((unsigned char*)spr_INTRO //sprite
,255 //tranparenca
,tbl_sprINTRO_x[i] //depart x
,i
,tbl_sprINTRO_w[i] //largeur x
,y+tbl_sprINTRO_x[i] //position x
,5+i //position y
);
*/

L'idée c'etait de restituer un sprite ligne par ligne en zappant les zones transparentes, et la finalité etait de ne plus utiliser la fct trans du sdk pour les enormes sprites. Mais comme j'ai jamais reussi a restituer un image sans bug (j'avais reinventé le cryptage canal + sur gp pour un sprite ) alors j'ai stoppé le massacre et tout mis le code en remarque ds mon code (voir si dessus).

coderMan dsl je m'etait un peu emporté mais en ce moment g la haine :-/

bon malgré la non motivation, le bedo et la haine g continué ma fonction, g optimisé comme je pouvais, apres c plus de mon niveau

ca bugue ac de grosse images (hauteur > ~100) clippé en y, mais tout depend de l'image
le clipping y est vachement lent

voila ^^ si qq veut tester, c par la.

yaouank :
Allez, on y croit. Deja t'avais choisi quoi comme convention pour ton encodage RLE ?
un octet pour le nombre de case a sauter, un octet pour la couleur du pixel d'apres ? Ou un truc plus fute ? (parce que comme ca si t'as plein de pixels de couleur differente qui se suivent, c'est moyen, t'as plein de "sauter 0 pixels" a lire)

C'est le drame de la compression RLE qui peut génèrer des images plus lourdes que l'image d'origine.

L'idée à utiliser pour gagner de la place si l'image a plusieurs séquences incompressibles (genre une séquence : 0 1 2 4 5 4 2 1 0). C'est de coder ton premier octet de deux façons :
1xxxxxxx : ça siginife que tu es face à un compteur d'itération, tu récupères l'octet suivant qui contient la couleur et tu affiches x fois la valeur et tu continues le décodage.
0xxxxxxx : c'est une simple valeur de couleur, tu l'affiches et tu continues ton décodage.

Ca marche bien mais si ton pixel dépasse la couleur 127... c'est mort et il faudra perdre deux octets pour afficher un seul pixel : 10000001 11000000

C'est une vague modif de l'algorithme RLE qui lui utilise 2 bits pour repérer les octets d'itération par rapport aux octets non compressés (vague souvenir).

J'espère avoir été à peu près clair.

Bon ben j'ai benché ma fct et apres optimisation avec l'aide de rov j'arrive à 1200 ticks pour un sprite 32*32 à nimporte quelle position (ça varie presque pas) avec clipping (et la mienne accepte les gfx + grand que 100*100 na ) et transparence bien sur (c le même sprite que rov que j'ai utilisé), contre 2500 pour gptransblt, ah oui et je compiel sous sdt. Je pourrais ptet arriver à encore un peu mieux, mais là j'en ai marre je continuerais plus tard