PureBasic

mouais enfin chui en train de tester tout ca...

*Ptr\l=couleur

pourquoi tu passe par un pointeur ici ?
on pourrais utiliser un poke non ? ca serais plus lent avec un poke ?

poke c'est une fonction, donc utilisation de la pile donc code plus lent

Dri

hum ok


j'ai encore une question :

La fonction Drawingbuffer () me renvoie 3584 ! comme ce fesse ?
ben oui je ne comprend pas, on est en 800*600*32bits

ca veut dire qu'une ligne fait 800 pixels * 4 (puisque 32bits) = 3200...
il y a un truc qui m'échappe là...

drawingbuffer renvoi une adresse, pas une taille
le temre buffer signifie tampon (memory buffer -> tampon mémoire =)

Dri

heu non pardon je voulais parler de la fonction drawingbufferpitch ()

dans l'aide il ya marqué ca :

Retourne la longueur réelle d'une ligne du buffer courant, en octets

et je ne comprend pas pourquoi elle ne me renvoie pas 3200... (800 * 4)

une igne c'est "largeur" * 4 si le pixel est en 32bits
(voir le format des pixels)

Dri

ben oui je m'en doute bien mais alors pourquoi la fonction DrawingbufferPitch () me renvoie 3584 et pas 3200 ???

En fait ça dépend du mode d'affichage , parfois le pitch correspond bien aux nombres de pixels * nombres octets par pixel.
Avec une résolution de 1024 pixels sur la largeur , le pitch correspond à ton calcul 1024 * 4 .

La différence que tu peux constater est , parait-il , pour garantir un alignement plus facile dans la mémoire.

ah bon ?

c'est bizarre ca...

alors a quoi correspondent les octets de chaques pixels ?

R,V,B, Alpha ?

oui R,V,B et alpha .

Je ne suis pas sûr , mais je crois que les octets supplémentaires ne servent à rien .

Si tu as 3584 octets , en fait tu n'as besoin que des 3200 premiers , les autres ne servent qu'à garantir l'alignement en mémoire .

ne me demande pas pourquoi , je n'en sais rien, c'est l'explication que j'avais obtenu , j'en suis resté là

ah bon... merci

bizarre quand même

Je savais pas ca ^^

Dri