EXEMPLE D'UTILISATION DE SETDIBITSTODEVICE

Commentaire de vecchio56 le 19/05/2006 00:35:10 administrateur CS

delete lpBits; ->  delete[] lpBits; (c'est un tableau)

Effectivement c'est beaucoup plus rapide de faire ca que de faire des SetPixel
En général, je n'utilise SetPixel que quand il y a une ou deux pixels à changer.
Dans ton exemple, je pense que FillRect sera encore plus rapide

Commentaire de vecchio56 le 19/05/2006 01:55:57 administrateur CS

Remplir des rectangles, c'est bien ce que tu fais dans ce code, non?

Commentaire de Taron31 le 19/05/2006 19:05:17

C'est sympa comme effet, et ça à l'air beaucoup moins lourd que d'utiliser SetPixel...
Ps: T'oublie un ReleaseDC()

Bon code.

Commentaire de SAKingdom le 20/05/2006 17:54:23

Bon j'ai optimiser le code en mode release. Il ne prend plus que 3.5Ko et n'utilise plus le CRT. Pas encore d'assembler. Je préfere éviter pour l'instant.

Commentaire de SAKingdom le 20/05/2006 21:28:17

Non non surtout pas sinon à koi bon poster cette source sur ce site. L'assembler c'est plutot pour les utilitaires et la fonction myWinMain car ça diminurais encore plus la taille du fichier exe.

Commentaire de vecchio56 le 20/05/2006 21:57:54 administrateur CS

C'est pourtant le code qui est dans le WM_TIMER qui mériterait d'être optimisé

Commentaire de BruNews le 20/05/2006 22:35:03 administrateur CS

for (y = 0; y < TABHEIGHT; y++)
xor ebx, ebx ;;; y = 0
lblFOR:
;;; divers codes
inc ebx
cmp ebx, TABHEIGHT
jb lblFOR

for (y = TABHEIGHT - 1; y >= 0; y--)
mov ebx, TABHEIGHT - 1
lblFOR:
;;; divers codes
dec ebx
jns lblFOR

On voit ici que boucler VERS 0 est toujours meilleur que DEPUIS 0, à transformer tant que faire se peut.

A part cela, il faudrait vérifier comment le compilo a généré la multiplication par 3 dans:
tmp = (TABHEIGHT-y-1)*bytewidth+3*x;
Si tu vois un "mul 3" alors remplacer par un "lea eax, [eax+eax*2]"

bytewidth : ne me semble pas être recalculé donc mettre en constante dans un #define, tu éviteras un accès mémoire dans les boucles pour chaque ligne vue plus haut.

Commentaire de BruNews le 21/05/2006 00:23:53 administrateur CS

mov         edx,dword ptr [x]
imul        edx,edx,3

C'est de la daube ce imul, au moins 12 cycles, remplacer par:
mov edx, dword ptr[x]
lea edx, [edx+edx*2]

Commentaire de vecchio56 le 21/05/2006 00:35:16 administrateur CS

Ca tombe sous le sens, ceux qui ne connaissent pas l'asm ne comprendront pas, de même que ceux qui ne connaissent pas le C ne comprennent pas la version actuelle

Commentaire de SAKingdom le 21/05/2006 00:43:08

Bon alors tu me conseille quoi pour tmp = (TABHEIGHT-y-1)*BYTEWIDTH+3*x? Je le laisse comme ça?

Commentaire de SAKingdom le 21/05/2006 00:54:45

Ah ok. Merci. Mais pour avoir un programme completement optimiser de cette façon, il faut soi: avoir beaucoup d'expérience ou avoir beacoup de temps devant soi non? Il faut vraiment penser au moindre petit detail. Évidament connaitre l'assembler ça aide beaucoup. Bon je mis remet. Merci encore.

Commentaire de BruNews le 22/05/2006 11:09:31 administrateur CS

le shift est mis en place de toute div ou mul si puissance de 2 directement par tout compilo moderne, il est clair que si tel n'eut pas été le cas je l'aurais mis.

Commentaire de MickCo le 22/05/2006 12:21:08

C'est un vieux réflexe. Je ne peux pas m'empecher d'optimiser le code moi-même.
S'il est vrai que les optimisations de compilations sont efficaces, on ne sait pas trop ce que fait réellement chaque compilateur. De plus, pour mon boulot, j'utilise les mêmes algos sur plusieurs plateformes differentes et donc plusieurs compilateurs differents (et plus ou moins evolués selon la plateforme). Donc, à la base, mieux vaut que j'optimise au max mon code sans trop savoir ce qu'a dans le ventre chaque compilateur.

Je n'ai plus que de vague souvenir de l'assembleur, mais il me semblais qu'un shift soit fait qu'en 1 seul cycle.
Il est vrai qu'avec la puissance actuelle des PC ainsi que les optimisations des compilateurs pour PC, j'ai délaissé l'assembleur depuis près de 10 ans.

En tout cas ton info est très interressante.
Si tu as des liens parlant des optimisations, je suis prenneur.

Commentaire de SAKingdom le 22/05/2006 15:06:01

Bon j'ai apporté les optimisations que BruNews ma suggéré. J'ai aussi remplacé ma fonction mymemset par myZeroMemory. Elle est en assembler. Ensuite, pour MickCo:

lpBits[tmp]=bluelevel;
lpBits[tmp+1]=greenlevel;
lpBits[tmp+2]=redlevel;
tmp += 3;

Le but de cette source est en partie d'expliquer comme le calcule des positions dans le buffer s'effectue. Si je fais tmp += 3, sa reviend à expliquer une méthode pour dessiner des rectangles. Hors avec ce que j'explique et avec un peut d'imagination, on peut tout faire avec ça même du 3D.

Commentaire de BruNews le 22/05/2006 21:03:44 administrateur CS

Allez une dernière:

myZeroMemory() boucle autant de tours que d'octets, pas terrible, il faut dérouler afin de faire le moins de sauts de code possible, c'est le plus pénalisant pour les perfs.

Exemple avec 8 octets (2 DWORDs) par tour:
__declspec(naked) void __fastcall bnZeroMemory(void *destination, UINT size)
{ // ECX = destination, EDX = size
  __asm {
    test  edx, edx
    mov   eax, edx
    je    short zeroEXIT
    and   eax, 7
    sub   edx, eax
    jz    short finHUIT
  parHUIT:
    mov   dword ptr[ecx], 0
    mov   dword ptr[ecx+4], 0
    add   ecx, 8
    sub   edx, 8
    jnz   short parHUIT
  finHUIT:
    test  eax, eax
    je    short zeroEXIT
  parUN:
    mov   byte ptr[ecx], 0
    inc   ecx
    dec   eax
    jnz   short parUN
zeroEXIT:
    ret 0
  }
}