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

jackiechan91 a écrit :
Je pense que cette fonction marche :

unsigned short Test(short x,short y,BITMAP *sprt)
{
	return (sprt->Data[((sprt->NumCols>>3)*y)+(x>>3)] & (1<<(7-(x%8))));
}

Et j'ai fait un bench, je suis arrivé à environ 13571 tests/s

huuuu, ça c'est de l'instruction !!

C'est joli

Ouai mais les >>3 et tout ça ne sont que des /8
C'est plus élégant et plus rapide surtout

Au lieu de %8, tu pouvais mettre &7.

C'est plus rapide ? Il me semblait que de mettre %8 revient exactement à faire &7.

Je pense que GCC optimisera ça automatiquement en effet.
Mais il ne faut jamais trop se fier du compilateur.

Bah je vais changer alors, merci.

En effet, je viens de faire un bench et c'est légèrement plus rapide.
Moi, je croyais que la seule solution pour faire x%y était de faire x & (y-1), donc je pensais que ça revenait exactement au même.
Mais alors qu'est-ce que le compilo fait quand on entre x%y, si ce n'est pas x & (y-1) ?

il y a quelques temps, j'avais regardé sir les % étaient optimisés en &, pour voir s'il fallait le faire soit même ou non...
(j'ai maté le résulats .s généré par TIGCC)

en O3, TIGCC optimise ça tout seul.
(du moins, pour les endroits où j'ai maté... je suppose donc que pr les autres aussi )

jackiechan91 a écrit :
Moi, je croyais que la seule solution pour faire x%y était de faire x & (y-1)

ca marche que si y est une puissance de 2.

En effet! 18%10==8, 18&9==0b10010&0b01001==0!

Ah ok.
Merci.

ça marche que pr les puissances de deux ?
erf...

Au fait, la fonction que j'ai donnée au post 55 est buggée : elle ne fonctionne correctement qu'avec les images dont la largeur est un multiple de 8.
Voici la nouvelle qui corrige cela, elle est un peu plus lente, alors si quelqu'un sait l'optimiser...

unsigned short Test(short x,short y,BITMAP *sprt)
{
	return (sprt->Data[(((sprt->NumCols>>3)+((sprt->NumCols & 7)?1:0))*y)+(x>>3)] & (1<<(7-(x & 7))));
}

Bench : 13571 tests/s

Impressionant... J'aimerais bien comprendre comme ça marche, mais en attendant je vais me contenter de l'utiliser

Au fait, ça n'a pas tellement de rapport mais je v pas créer un topic pour ça :
Pkoi je ne peux pas faire BitmapSize(&(SCR_RECT){{0,0,10,10}}) ? Du coup je suis obligé de définir par exemple SCR_RECT zone={{0,0,10,10}} puis faire BitmapSize(&zone)...

Bob 64
a écrit : Pkoi je ne peux pas faire BitmapSize(&(SCR_RECT){{0,0,10,10}}) ?

Quelle version de TIGCC?
Avec la bêta 18, je n'ai pas de problème.

Bon ok je suis encore en retard...
v d/l la dernière version...

ça marche

Autre problème...
Je cherche à convertir un fichier PIC du TiOS en Bitmap :

if(peek(HToESI(sym_var->handle))==0xDF)
{
chr_pic=HeapDeref(sym_var->handle);
memcpy(bit_var,HeapDeref(sym_var->handle)+2,BitmapSize(&(SCR_RECT){{1,1,*(unsigned int*)(chr_pic+4),*(unsigned int*)(chr_pic+2)}}));
}

*(unsigned int*)(chr_pic+4) correspond à la dimention X du PIC et *(unsigned int*)(chr_pic+2) à la dimention Y. On a donc le BitmapSize qui retourne le nombre d'octets à copier, à partir du 3eme du fichier PIC : HeapDeref(sym_var->handle)+2
Mais à chaque fois y'a le bas de l'image qui n'est pas bon, pourtant il me semble bien que j'ai pas fait d'erreur de mémoire

Les deux premiers octets contiennent la taille du fichier, donc si tu fais :
memcpy(bit_var,HeapDeref(sym_var->handle)+2,*((short *)HeapDeref(sym_var->handle))-1);
ça devrait marcher...

En fait le problème était ailleurs
Mais ton truc va quand même être utile, merci

D'ailleurs, mets plutôt (unsigned short *) avant le HeapDeref, sinon ça ne marchera qu'avec des fichier dont la taille est inférieure à 32768 octets

Tant qu'on y est, y'a pas un moyen rapide de mettre un buffer à 0 ?
Parceque mon écran virtuel char[3844], quand je fais memset(buffer,0,3844) ça dure un certain temps

t'1 ça fait 26.000 fois que cette question est posée
Tu peux reprendre cette fonction de la bibliothèque Azur :

GX_clrscr:
; Code provenant de la bibliothèque Azur
; Optimisation : Julien Monville
 movem.l d3-d7/a2-a7,GXSvgReg
 move.l  4(a7),a7
 lea     3840(a7),a7
 moveq   #0,d0
 moveq   #0,d1
 moveq   #0,d2
 moveq   #0,d3
 moveq   #0,d4
 moveq   #0,d5
 moveq   #0,d6
 move.w  d0,a0
 move.w  d0,a1
 move.w  d0,a2
 move.w  d0,a3
 move.w  d0,a4
 move.w  d0,a5
 move.w  d0,a6
 moveq   #10,d7
GXCS_loop:
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 dbf     d7,GXCS_loop
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0,-(a7)
 movem.l GXSvgReg(pc),d3-d7/a2-a7
 rts
GXSvgReg:
 ds.l    5+6

Le prototype : void GX_clrscr(void *plane)

Ouais... Heu... Tout compte fait memset est suffisant

Bon y'a plus important :
Voilà la routine de Jackiechan91 pour tester l'état d'un pixel dans un Bitmap :

unsigned int drw_ptst(BITMAP *bit_var,int int_psx,int int_psy)
{
return bit_var->Data[(((bit_var->NumCols>>3)+((bit_var->NumCols & 7)?1:0))*int_psy)+(int_psx>>3)] & (1<<(7-(int_psx & 7)));
}

J'ai fait des comparatifs avec "afficher le Bitmap sur un écran virtuel, puis scanner avec EXT_GETPIX". Le getpixel d'extgraph est très légerement plus rapide, mais je pense qu'en optimisant la routine de Jackiechan on doit pouvoir renverser la balance. Est-ce que qqun peut... ?

)>>3)] & (1<<(7-((int_psx) & 7)))))Tu remplaces la fonction par ceci :#define drw_ptst(bit_var,int_psx, int_psy) ((unsigned int)((bit_var)->Data[((((bit_var)->NumCols>>3)+(((bit_var)->NumCols & 7)?1:0))*(int_psy))+((int_psx
Je parie que la balance est inversée

Eh non

En fait je me suis planté ds mes calculs, extgraph a une bonne marge d'avance quand même

Et oui, TICT rulez!

Jackie >> j'ai vraiment pas compris ta fonction ! tu peux expliquer sa méthode de repérage des bits stp ? car là faudrait que je comprenne tt de même !

Jackiechan si tu lui explique fais le en public stp, comme ça je pourrais en profiter aussi

Kevin > Au lieu de vanter les mérites de la TICT () t'as pas une optimisation en tête, par hazard ?

puisque c comme ça, je debugue ma fn tout de suite
++

g pas eu le temps.