Salut,

Je me demandais si il existe une manière de récupéré la couleur d´un pixel précis sur une surface. Ceci servirais dans un contexte comme :

( pseudo code)

if ( ( pixel(x,y).couleur ) == vert )
. ...
else
. ...

Merci,
Psy

je ne connais pas SDL, mais si ça passe comme dans la plupart des API graphiques, regardes si tu peux pas locker ta ressource ( texture, target, backbuffer, etc.) pour obtenir un pointeur vers les données des pixels...

Merci pour ta réponse, j´suis désolé de t´avoir réveilé

Uint32 getpixel(SDL_Surface *surface, int x, int y)
{
int bpp = surface->format->BytesPerPixel;
/ * p est l´adresse du pixel à tester */
Uint8 *p = ( Uint8 *)surface->pixels + y * surface->pitch + x * bpp;

switch(bpp) {
case 1:
return *p;

case 2:
return *(Uint16 *)p;

case 3:
if(SDL_BYTEORDER == SDL_BIG_ENDIAN)
return p[0] < < 16 | p[1] < < 8 | p[2];
else
return p[0] | p[1] < < 8 | p[2] < < 16;

case 4:
return *(Uint32 *)p;

default:
return 0; / * Ne devrait pas arriver mais évite les avertissements */
}
}

Voilà la fonction, après faut penser à locker la surface et unlocker la surface après, ou bien tu peux rajouter le lock/unlock directement dans la fonction getpixek() ; )

" ou bien tu peux rajouter le lock/unlock directement dans la fonction getpixek()"

SDL n´est-il pas une encapsulation, et ne se base-t-il pas, sous win, sur DX ou GL pour le tracé ? Si c´est le cas, ce serait à proscrire, sans quoi selon la gestion des ressources c´est le bus AGP qui risque de déclarer forfait ( quoique on en voit tres bien, meme sur des forums pros, qui s´étonnent de mettre leur machine à genoux avec des textures jpeg de 2048x2048 sans aucune précaution...)

LGV -> Ah désolé moi je connais pas trop

Mais si tu dis que saymal, j´veux bien te croire...D´ailleurs moi je lockais hors de la fonction donc je sais pas cque ça fait de locker dans la fonction, mais vu de mon niveau ça me paraissait pas un truc qui pourrait générer des problèmes.

Désolé

c´est sur le principe que c´est interessant de comprendre... Dans une archie moderne, les ressources ( graphiques ici) se baladent un peu partout : mémoire de la carte, mémoire du systeme, unité de calcul du GPU, voire duplication synchrone ou pas, etc. Donc à priori " on ne sait pas trop" où se trouve sa texture, entre autres ( meme si selon les APIs on peut décider de la gestion des ressources) ; le lock a justement pour effet de garantir que la ressources est bien accessible au systeme : ça veut dire que quand tu lockes une texture qu´est dans la VRAM de la carte, il faut la transferer jusque dans le RAM principale, où tu peux obtenir un pointeur valide ; et quand tu unlock, c´est l´inverse, les infos dans la carte sont mises à jour pour garder la cohérence. A chaque fois, c´est le bus AGP qui déguste : un lock par pixel, ça va plus faire slideshow qu´appli interactive...
Deja le lock " c´est mal", souvent on peu s´en passer, mais quand on en a vraiment besoin, faut bien penser aux implications en termes de performances. Bon quand je dis ça je pense surtout 3D, c´est sur qu´en 2D pour mettre à jour votre surface, vous avez pas d´autre choix que de locker Disons que locker une ressource plus d´une fois par frame, faut revoir son appli

exemple sur le site officiel :

http://sdldoc.csn.ul.ie/guidevideo.php#AEN112

par contre, oui, pense a locker la surface
le lock est une opération lente : lock une fois pour toutes, fait toutes tes modifs, puis délock

Merci de vos réponse.

1. include < windows.h>

COLORREF GetPxlColor(int XPos,int YPos)
{
long HwndSrc,HsrcDC;
COLORREF Pxl;
HwndSrc = GetDesktopWindow();
HSrcDC = GetDC(HwndSrc);
Pxl=GetPixel(HSrcDC,XPos,nYPos);
ReleaseDC(HwndSrc, HSrcDC);

return Pxl;
}

Vive WIN32 ! !!!

ben ça change rien... A part si tu fais du win32 pur ( mais bon, je vois pas l´interet de se lancer dans un truc graphique dans ce là), des que tu fous SDL, DX ou openGL, le contexte va etre raccroché aux ressources de rendu, et du coup le GetDC il fait quoi . . il stalle tout le pipeline car la destination n´est plus dispo :/

oups, j´ai oublié qu´en C on ne déclare pas les pointeur comme des long, donc voici une version qui marche :

1. ifndef _WINDOWS_
2. include < windows.h>
3. endif

COLORREF GetPxlColor(int XPos,int YPos)
{
HWND HwndSrc;
HDC HSrcDC;
COLORREF Pxl;
HwndSrc = GetDesktopWindow();
HSrcDC = GetDC(HwndSrc);
Pxl=GetPixel(HSrcDC,XPos,YPos);
ReleaseDC(HwndSrc, HSrcDC);
return Pxl;
}

Et COLORREF est homogène à un DWORD, donc un unsigned long je dirait.

LGV : je sais pas, je trouve que c´est finalement plus simple en win32 qu´en SDL.

Mais c´est pour les archives disont que je donne cette version, comme ça si un jour qqn trouve ce thread, mais ne veut pas utiliser SDL, il pourra utiliser win32.

il a interet a bien fouiller quand meme ; ) enfin, toute idée est bonne à prendre !

plus simple, pas forcément, plus masqué, oui... Si tu regardes ce qui se passe derriere les histoires de contexte, gerer correctement sont affichage pour faire des choses évoluées ( autre que reprogrammer ses MFC maison quoi...) c´est loin d´etre trivial :/