Stockage et lecture d'octets ... - Page 1

Mon problème est le suivant : je désire stocker un sprite (16*16) sous la forme d'octets (sous la forme 00000000 00000000,11111111 11111111, ... donc) et j'ai besoin d'accéder à chacun des pxl de ce sprite par des coord x et y (c surtout le x qui me pose pb )
Donc j'ai deux questions :

1)comment dois-je définir ce sprite ?
2)comment lire ce sprite ?

Je vous remercie.

1) Soit tu fais 0b00100100 soit en héxa -> 0x24
2) Pour le lire pixel par pixel ?

unsigned short lire(short x, short y,short *sprt)
{
 return (sprt[y] & 1<<(15-x))
}

(Pour un sprite 16x16 de type short)

et tu fais var=lire(0,0,ton_sprite) pour lire le premiers pixels, si je ne me suis pas trompé... et si var>0 c'est que le pixel est noir, sinon, var sera nul : pixel blanc.

et var prends pour valeur soit 1, soit 0 ?
c rapide ou pas ?

var est soit strictement supérieur à 0 (dans le cas d'un pixel noir), soit nul (pixel blanc)

Par contre, je ne sais pas si c'est rapide, à mon avis ça l'est assez (une addition, un ET et un décalage de bits, ça doit pas être très long, tout ça), mais c'est sûrement optimisable...

pas de valeur particulière qd c >0 ?

et niveau rapidité ça le fait ou pas trop ?

pas trop à mon avis.

quand c est >0, il peut prendre les valeurs suivantes : 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384 ou 32768.

Pen² ?
t'as une méthode plus rapide ?

Mais tu n'as qu'à tester si ça marche, déjà, puis si c'est rapide...

ben si c lent ça va pas me servir à grand chose
pour l'instant mon sprite c un tbl de char sprt[16][16] et pour savoir si y'a un pixel à allumer ben je fait un test if(sprt[y][x]) ...

et ma méthode actuelle est irrecevable pour des gros sprites type 64x64 > ça prends trop de place

oué bof, g rien dit, c pas mal en fait.
faudrait voir en asm.

pourquoi ce changement d'avis si soudain ?

Vark a écrit :
ben si c lent ça va pas me servir à grand chose pour l'instant mon sprite c un tbl de char sprt[16][16] et pour savoir si y'a un pixel à allumer ben je fait un test if(sprt[y][x]) ...

c juste pour afficher le sprite que tu veux ta routine ??

nan
c pour faire un rotozoom (pour l'instant g fait que le zoom )

Vark
a écrit : pourquoi ce changement d'avis si soudain ?

j'av pas bien lu l'ennoncé.

mais est-ce que ça va être au moins aussi rapide sinon plus que ma méthode actuelle ?
g besoin d'un truc qui fuse

Pourquoi tu fais un tableau de char sprt[16][16] ?
Ce serait mieux de faire short sprt[16].
Ou alors j'ai pas bien compris ce que tu voulais dire.

si je fait un short sprite 16 je c pas comment accéder à un pixel d'une abscisse x

TU N'AS QU'À TESTER POUR COMPARER AVEC TON ANCIENNE MÉTHODE...

pour le rotozoom, faut que tu fasses le zoom et la rotation en une seule passe, ne fais pas d'abord le zoom et ensuite sur le truc obtenu une rotation, tu n'arriveras pas à qq chose de rapide.

et pour ton zoom, tu n'utilises pas déjà un getpixel ?

Ben avec ma technique ça devrait marcher pour accéder à un pixel d'abscisse x.

Pen²> je c, g juste à modifier les composante de mon vecteur de parcours pour ajouter la rotation !!!!

et pour mon zoom je teste si la case de coord(u,v) du sprite (défini en tbl de char[][] pour l'instant ) est pleine, si oui ben je put le pixel ...

Et pour afficher ton sprite tu fais comment ?

bon, valà mon source :
zoom=256; zold=0; while(1) { if(zoom!=zold) {   yd=20;   xd=40;   ClearGrayScreen2B(GetPlane(0),GetPlane(1));   add=(yd<<5)-(yd<<1)+(xd>>3);   ptr0=GetPlane(0)+add;   ptr1=GetPlane(1)+add;   v=0;   while(v<4096)   {     x=0;     u=0;     while(u<4096)        {       spr=0x80>>((x)&7);          if(triso_C0[v>>8][u>>8])       *(ptr0+(x>>3))|=spr;          if(triso_C1[v>>8][u>>8])       *(ptr1+(x>>3))|=spr;             x++;             u+=zoom;        }     v+=zoom;        ptr0+=30;        ptr1+=30;      } } zold=zoom; if(_rowread(0x2FF)&0x40)   goto end; if(_rowread(0x2FF)&0x10&&zoom>40)   zoom-=8; if(_rowread(0x1FF)&0x1&&zoom<256)   zoom+=8; }

Au fait, je m'étais trompé plus haut, dans la fonction, mais c'est corrigé

ok
v essayer ça...

Et je viens de corriger une deuxième erreur que j'avais faite...

c'est bon, je pense qu'elle marche. Le résultat est du type UNSIGNED. Si il est stocké dans une var signed, le résultat d'un test aux coordonnées 0,0 sera égal à -32768 au lieu de 32768.
Les arguments x et y peuvent prendre des valeurs allant de 0 à 15 tous les deux.

J'ai fait une espèce de bench, j'ai trouvé 27636 tests/s....

je viens de tester : ma méthode est bcp plus rapide ...

bon ben je c ce que je v faire

v stocker les sprites en short[16] et au début du prog v les convertir en char[16][16] (la ram va en chier qd je v faire plus gros )

sinon si kelkun a une idée plus rapide je suis pas contre