Discussion :

[loupapet]

Bonjour, Bonsoir,

Voici une bonne semaine que je "cafouille" avec mon application. J'ai cherché sans succès sur les forums et dans les documentations de la SDL2.0. Désolé, j'ai peut-être mal cherché ou je ne suis pas très malin. J'espère que vous pourrez m'aiguiller si c'est possible. D'avance, merci.

Mon problème est d'une simplicité biblique, la solution doit certainement l'être aussi, je ne l'avais pas eu en SDL 1.2. Voici donc l'énoncé :

Après avoir affiché une palette de couleur, il s'agit tout simplement de récupérer la couleur d'un pixel indiqué avec la souris
pour l'affecter à une entité graphique, trait, cercle, courbe de Béziers, texte, etc...

Quoi de plus classique ? 3 questions s'il vous plaît :

• Quel est l'enchainement des paramètres des structures partant de celle de la fonction "SDL_Window" pour arriver à celle de la fonction "SDL_Surface" dans laquelle se trouve le pointeur sur la pixelmap de la surface ?
• Avec quelle fonction peut-on synchroniser la surface (SDL_GetWindowSurface()" associée à celle de la fenêtre principale "SDL_CreatWindow()" ?
• Où peut-on trouver la description des paramètres des deux structures "SDL_Window" et "SDL_Renderer" que je n'ai pas réussi à afficher sous le debugger ni trouvé dans les ".h" ?

Je pensais que la fonction "SDL_GetWindowSurface", à la ligne 92, allait être la solution en donnant l'adresse de la pixelmap de la surface associée. Hélas, je m'y cogne lamentablement, la pixelsmap est pleine de zéros et je n'ai pas trouvé le moyen d'effectuer une synchronisation avec la pixelmap de la fenêtre principale de l'application ("SDL_Update... quelque chose").

Pour illustrer le problème, j'ai sérieusement élagué mon application pour proposer l'exemple simplifié ci-dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
#include <string.h>
#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <SDL2/SDL.h>
 
  SDL_Window             *fenetre = NULL  ;
  SDL_Surface    *surface_fenetre = NULL  ;
  SDL_Renderer      *moteur_rendu = NULL  ;
  SDL_Event             evenement         ;
  int             largeur_fenetre = 784   ;
  int             hauteur_fenetre = 560   ;
  int            touche_caractere         ;
  int               bouton_souris         ;
  int             roulette_souris         ;
  int                   xs_souris         ;
  int                   ys_souris         ;
  bool                 traitement = false ;
 
//=============================================================================================================================
Uint32 getpixel(SDL_Surface *surface, int x, int y)
{
  int bpp = surface->format->BytesPerPixel;
  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;
  }
  return 0 ;
}
 
//=============================================================================================================================
int affiche_palette( SDL_Renderer *moteur_rendu, int  xsg, int ysg, int largeur, int hauteur)
{
  int      couleur, larg, haut, i, j, ibv, jbh, dv, dh ;
  int y ;
  Uint8    r,v,b, rr, vv, bb ;
 
  larg = largeur/6 ;
  haut = hauteur/2 ;
 
  for (ibv=0 ; ibv < 6 ; ibv++)
  {
    for (i=0 ; i < 256 ; i++)
    { dv = (larg*i)/255 ;
 
      switch(ibv)
      { case 0 : r = 0xFF  ; v =   i   ; b = 0x00  ; break ;
        case 1 : r = 255-i ; v = 0xFF  ; b = 0x00  ; break ;
        case 2 : r = 0x00  ; v = 0xFF  ; b =   i   ; break ;
        case 3 : r = 0x00  ; v = 255-i ; b = 0xFF  ; break ;
        case 4 : r =   i   ; v = 0x00  ; b = 0xFF  ; break ;
        case 5 : r = 0xFF  ; v = 0x00  ; b = 255-i ; break ;
      }
 
//    for (y = 0 ; y < hauteur ; y++) pixelRGBA(moteur_rendu, xsg + ibv*larg + dv, ysg + y, r, v, b, 0xFF) ;
 
      for(jbh=0 ; jbh < 2 ; jbh++)
      {
        for (j=0 ; j < 256 ; j++)
        { dh = (haut*j)/255 ;
 
          switch(jbh)
          { case 0 : rr = (r*   j   )/255 ; vv = (v*   j   )/255 ; bb = (b*   j   )/255 ;  break ;
//                   rr = r-     r *(255-j)/255 ; vv = v-     v *(255-j)/255 ; bb = b-     b *(255-j)/255 ;  break ;
            case 1 : rr = r+(255-r)*j/255 ; vv = v+(255-v)*j/255 ; bb = b+(255-b)*j/255 ;  break ;
          }
          pixelRGBA(moteur_rendu, xsg + ibv*larg + dv, ysg + jbh*haut + dh, rr, vv, bb, 0xFF) ;
        }
      }
 
    }
  }
  return(0) ;
}
//===============================================================================================================================
int SDL_main(int argc, char* argv[])
{
  Uint8 r,v,b, r1,v1,b1 ;
 
  SDL_Init(SDL_INIT_VIDEO | SDL_INIT_EVENTS) ;
  atexit(SDL_Quit) ;
  fenetre = SDL_CreateWindow( "Test SDL_Window / SDL_Surface"
                            , SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED
                            , largeur_fenetre, hauteur_fenetre
                            , SDL_WINDOW_RESIZABLE | SDL_WINDOW_SHOWN
                            ) ;
 
  surface_fenetre = SDL_GetWindowSurface(fenetre) ;
 
  moteur_rendu = SDL_CreateRenderer( fenetre
                                   , -1
                                   , SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC
                                   ) ;
 
  affiche_palette(moteur_rendu, 150,150, 500, 300) ;
  SDL_RenderPresent(moteur_rendu) ;
 
  touche_caractere = -1 ;
  traitement       = false ;
  while (touche_caractere != SDLK_ESCAPE)
  {
    while (SDL_PollEvent(&evenement))
    {
      SDL_GetMouseState(&xs_souris, &ys_souris) ;
      switch(evenement.type)
      { case SDL_QUIT:
             touche_caractere = SDLK_ESCAPE ;
             break ;
 
        case SDL_MOUSEBUTTONDOWN :
             bouton_souris = evenement.button.button ;
             traitement = true ;
             break ;
 
        case SDL_KEYDOWN :
             if (evenement.key.keysym.sym == SDLK_ESCAPE) touche_caractere = SDLK_ESCAPE ;
             break ;
      }
      if (traitement == true) break ;
 
    } // => fin du while (SDL_PollEvent(&edgr_comm.evenement))
 
    if (traitement == true)
    {
      traitement = false ;
 
    //=================================================================
      Uint8 *pixel = (Uint32*)surface_fenetre->pixels ;
 
      SDL_LockSurface(surface_fenetre) ;              // on verrouille la surface (conseillé dans la doc)
      int dpl = ys_souris*surface_fenetre->w + xs_souris ;
      r = pixel[dpl+0] ;
      v = pixel[dpl+1] ;
      b = pixel[dpl+2] ;
 
      Uint32 point = getpixel(surface_fenetre, xs_souris, ys_souris) ;
      SDL_GetRGB(point, surface_fenetre->format, &r1, &v1, &b1) ;
      SDL_UnlockSurface(surface_fenetre) ;
 
      printf(" Rouge,Vert,Bleu direct     : %d(0x%02x) , %d(0x%02x) , %d(0x%02x)\n",  r,  r,  v,  v,  b,  b) ;
      printf(" Rouge,Vert,Bleu SDL_GetRGB : %d(0x%02x) , %d(0x%02x) , %d(0x%02x)\n", r1, r1, v1, v1, b1, b1) ;
    //=================================================================
 
      SDL_RenderPresent(moteur_rendu) ;
      SDL_Delay((Uint32) 20) ;
    }
  } // fin du while (edgr_comm.touche_caractere != SDLK_ESCAPE)
 
  SDL_DestroyRenderer(moteur_rendu) ;
  SDL_DestroyWindow  (fenetre     ) ;
  SDL_Quit() ;
  exit(EXIT_SUCCESS) ;
}

Quelqu'un peut-il me dire ce que je ne fais pas correctement ? Ou bien où aller chercher les informations ?

Il est quand même surprenant que les développeurs de la SDL ne fournissent pas en standard une fonction du type

"int SDL_RenderGetPoint(SDL_Renderer* renderer, int x , int y, Uint8*r, Uint8*v, Uint8*b) ;"

qui serait le symétrique de la fonction existante

"int SDL_RenderDrawPoint(SDL_Renderer* renderer, int x , int y) ;"

sachant qu'un système non symétrique est généralement incohérent.

En vous remerciant d'avance. Cordialement.

Lou Papet

[LittleWhite]

Bonjour,

À mon avis, il ne faut pas utiliser de SDL_Renderer lorsque vous voulez avoir un accès direct à la surface. Pour afficher les sprites, il suffit d'utiliser la « méthode SDL 1.2 ».
Je vous conseille aussi de lire le guide de migration (surtout la partie vidéo).

L'aspect non symétrique de l'API est lié au mécanisme de son fonctionnement interne. En effet, maintenant, le rendu est pensé et prévu pour être du côté GPU. Le SDL_Renderer travaille complètement sur la mémoire vidéo (celle du GPU). Même les fonctions DrawPoint() le font. L'histoire est que la récupération de la valeur d'un pixel en mémoire GPU, pour l'avoir côté CPU (utilisable dans le programme) c'est lent. J'ai envie de dire : « très lent ». Du coup, c'est une chose déconseillée.

Votre problème est lié à cette séparation CPU / GPU. En effet, une SDL_Surface, c'est une surface coté CPU. Une SDL_Texture, c'est une « surface » côté GPU.
Mon hypothèse actuelle est que vous devez faire le SDL_GetWindowSurface() après le rendu afin d'avoir une surface à jour (une copie à jour). De plus, si après cela, vous travaillez sur la surface, vous devez la renvoyer au GPU avec SDL_UpdateWindowSurface().

[loupapet]

Bonjour LittleWhite,

Je reprends aujourd'hui le fil de la discussion et vous remercie infiniment pour votre réponse.

Bien sûr, j'ai consulté le guide de migration vers la SDL-2.0. C'est la première chose que j'ai faite sitôt la SDL-2.0 installée. Vous l'aurez peut-être remarqué dans le code que j'ai fourni, j'ai utilisé le "Renderer" comme cela était dit alors que vous, vous me le déconseillez. Par ailleurs, j'avais trouvé un intérêt au "Renderer" car il me fournissait les fonctionnalités de tracé de point, de droites, de textes TTF et d'image ce qui m'évitait de les reconduire ici alors que j'avais été obligé de le faire avec la SDL-1.2. Si vous êtes curieux vous pouvez jeter un œil sur mon site sans prétention à la rubrique ""Le Noyau Graphique d'Images structurées"" où la SDL-1.2 est utilisé au minimum dans ce cas précis.

J'ai fais comme vous dites : placer l'appel à la fonction "SDL_GetWindowSurface(fenetre)" après la création du Renderer avec "SDL_CreateRenderer(..)". Malheureusement, rien y fait, ma pixelsmap est toujours remplie de pixels à zéro.

Merci aussi pour les justifications du manque de symétrie de la nouvelle orientation de la SDL-2.0 que vous semblez beaucoup apprécier.

Si vous me le permettez, je vous exprime un avis personnel. Je ne suis pas un voltigeur de la SDL. Je suis un programmeur un peu expérimenté mais de bas niveau comme il y en a des millions sur la planète. Ce que je n'apprécie pas du tout chez les développeurs-système de SDL, comme ceux de GTK d'ailleurs, c'est leur irrésistible tentation de faire des choses, probablement extrêmement évoluées et puissantes, qui n'intéressent qu'eux mêmes et peut-être même pas 10% des usagers, sans se soucier le moins du monde des millions d'heures de perdues par les utilisateurs d'applications qui se servent de l'informatique en tant qu'outil et non en tant que finalité. Le nombre de problèmes soulevés par un logiciel est inversement proportionnel à sa qualité si j'en juge aux différents forums dans lesquels, les questions sont récurrentes.

Je puis vous assurer que, en tant qu'ingénieur-système informatique d'entreprise au sein de mon équipe, si nous nous étions comportés de la sorte à l'époque avec notre modeste centaine d'utilisateurs finaux du Bureau d'Etudes, des Essais en Vol, des Essais Sol, de la Fabrication secteur commandes numériques et secteur électricité, nous aurions pris la porte dans de brefs délais.

Je constate que c'était une autre époque où une équipe-système était entièrement au service des usagers et non le contraire. Le point focal de nos préoccupations était la compatibilité ascendante, la formation minimale et autoformation maximale pour une meilleure productivité ce qui n'était pas toujours facile. Les changement de versions de systèmes d'exploitation en particulier devaient s'effectuer dans la transparence et si possible en arrêtant les CPU's le moins possible, donc la nuit, les jours de congés même les jours de Noël et de nouvel an, etc....

Enfin, pour terminer ma tirade, surtout pas contre vous, vous vous en doutez bien, en espérant ne pas vous ennuyer, pensez-vous que les développeurs-systèmes de SDL et de GTK répondent bien aux "Règles d'or de la programmation" que vous avez exposées dans votre site ?

En attendant, je suis toujours coïncé : Comment récupérer la couleur d'un pixel en SDL-2.0 sans être obligé de revenir à la version SDL-1.2 qui me ferait perdre encore beaucoup de temps ?

Cordialement.

Lou Papet

[Kannagi]

Bah rien ne vous empêche de rester sur la SDL 1.2 , pour ma part je reste sur la SDL1.2 vu qu'elle me satisfait.
Je crois pas qu'il faut voir cette migration obligatoire mais plutôt de cette manière la :
SDL 1.2 = Software
SDL 2.0 = Hardware

Donc oui il y a forcément une non symétrie.
Les systemes évolue donc la SDL évolue aussi avec , la SDL1.2 est une version finalisé d'un coter mais elle passe a coté de tout les améliorations de ces 15 dernière années en terme de GPU.

[LittleWhite]

J'ai fais comme vous dites : placer l'appel à la fonction "SDL_GetWindowSurface(fenetre)" après la création du Renderer avec "SDL_CreateRenderer(..)". Malheureusement, rien y fait, ma pixelsmap est toujours remplie de pixels à zéro.

Peut être je me suis mal exprimé, moi je disais de le faire après les ordres de dessin . Plus précisément : après le SDL_RenderPresent(). Ou, après afficher_palette. En effet, le SDL_Renderer dessine en mémoire GPU. Le SDL_GetWindowSurface permet d'avoir une copie de cette mémoire, mais utilisable par le CPU (par votre programme). Toutefois, si vous récupérez la copie avant d'afficher quoi que ce soit, alors votre copie sera vierge. C'est pour cela qu'il faut déjà modifié le tampon côté GPU, puis le copier pour l’analyser.

J'apprécie la SDL 2 car elle corrige des problèmes de la SDL 1 et qu'elle utilise l'accélération graphique ce qui la rend rapide (et utilise la puissance de la machine). Pour ce qui est jouer avec les pixels/récupérer la couleur de la surface, je la trouve atroce .

Je ne veux pas critiquer votre travail, ni votre expertise. Toutefois, j'ai du mal à être de votre côté (et cela n'est pas pour défendre la SDL 2).
Vous avez une utilisation précise de la SDL qui est :

lire et écrire les pixels à la main.

Pour que cela soit possible avec le matériel actuel, vous avez deux fois :

• vous avez votre tampon image sur le GPU (cas "normal" actuellement) ;
• vous faites du dessin, sur le GPU ;
• vous devez travailler sur votre dessin, avec le CPU, vous copiez donc le tampon en mémoire CPU ;
• vous faites votre travail. Si vous voulez mettre à jour le tampon GPU, vous devez faire une copie inverse ;
• et vous affichez à l'écran

Maintenant, si vous voulez faire du rendu quasi que CPU :

• vous créez un tampon (SDL_Surface) côté CPU (vous pouvez même le faire à la main) ;
• vous faites votre dessin ;
• vous l'envoyez sur le GPU / écran avec SDL_UpdateWindowSurface().

Cette seconde technique est plus simple. Après le SDL_UpdateWindowSurface() vous pouvez faire du rendu avec le GPU, si nécessaire, même si cela peut donner quelques soucis.

Pour en revenir sur l'histoire de la SDL 2, son but c'est de :

• ouvrir une fenêtre ;
• gérer les événements ;
• faire un rendu de surface (aussi rapide que possible car nous voulons gérer des centaines de sprites sur de grandes résolutions) ;
• ...

Si vous preniez la SDL 1, regardez les performances : http://alexandre-laurent.developpez....ces-de-la-SDL/
On ne peut pas avoir de grande et belles résolutions, alors que l'on arrive à l'air du 4K. Cela est du au fait que tous les calculs de la SDL 1.2 sont sur le CPU. Il fallait absolument passer au GPU. Donc oui, la SDL 2, remplit son objectif. Mais, le passage au GPU vous empêche de faire votre but précis. Pourtant, la SDL 2 a gardé assez d'anciennes choses pour que ce soit possible. Votre objectif est annexe par rapport aux vrais objectifs de la SDL.
La SDL 2 est utilisé dans de très nombreux jeux et projets pro et cela marche. Juste, les projets pro n'ont plus besoin de faire les choses que vous voulez faire.

Mais il faut comprendre que c'est principalement du à l'architecture actuelle de nos machines (séparation GPU / CPU et de leur mémoire). Par rapport à ce que vous voulez faire, l'architecture d'un Amiga ou Atari ST était mille fois mieux.

[loupapet]

Bonjour Kannagi,

Bah rien ne vous empêche de rester sur la SDL 1.2 , pour ma part je reste sur la SDL1.2 vu qu'elle me satisfait.
Je crois pas qu'il faut voir cette migration obligatoire mais plutôt de cette manière la :
SDL 1.2 = Software
SDL 2.0 = Hardware

Donc oui il y a forcément une non symétrie.
Les systemes évolue donc la SDL évolue aussi avec , la SDL1.2 est une version finalisé d'un coter mais elle passe a coté de tout les améliorations de ces 15 dernière années en terme de GPU.

Merci.

Vous avez raison, mais comme le projet était nouveau, tant qu'à faire, il me paraissait préférable de passer à la SDL-2.0 pour utiliser les fonctions du Renderer. Quant au gfx il existait déjà en SDL-1.2.

[loupapet]

Bonjour LittleWhite,

Encore mille merci pour le temps que vous me consacrez et pour toutes ces explications.

Mais je n'ai pas encore baissé les bras même si cela m'embête de passer du temps à me dépatouiller avec des fonctionnalités-système alors que je suis plus intéressé de progresser dans mon application qui ne demande pas des performances graphiques mirobolantes.

Je vais essayé de faire ce que vous dites. Cela me paraît logique.

Je comprends le désir de performance des développeurs mais je ne comprends pas la censure qu'ils pratiquent. Il leur est extrêmement facile de placer un pixel dans une surface, il leur est tout autant de faire l'inverse. Ils ne doivent pas s'en priver. Pourquoi alors interdisent-ils d'en récupérer un sans avoir à faire l'arbre droit ? Personnellement, je n'ai jamais pratiquée cette censure dès lors qu'elle ne mettait pas en péril mon installation et qu'elle préservait les informations privées, bien au contraire, on avait tendance à me reprocher de trop en dire ce que ne m'enlevait absolument rien du tout.

Certes, ce n'est pas à un mois de mes 75 ans que je vais commencer à changer le monde, la place est aux jeunes. Je me contente de prendre ce que l'on veut bien me donner mais pourquoi, diable, avec des #typedef appropriés et des CHECK... dans leurs compiles, si j'ai bien compris, empêchent-ils l'accès à la surface figurant dans la structure SDL_Window et SDL_Renderer entre autres ce qui permettrait d'utiliser les deux fonctions (en 32 bits) ci-dessous, d'une simplicité diabolique, que vous connaissez bien mieux que moi et qui sont :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Uint32 lecture_pixel( SDL_Surface *surface, int x, int y)
{
 Uint32 *pixels = (Uint32 *)surface->pixels ;
 return pixels[y*surface->w + x] ;
}
void ecriture_pixel32( SDL_Surface *surface, int x, int y, Uint32 pixel)
{
  Uint32 *pixels = (Uint32 *)surface->pixels ;
  pixels[y*surface->w + x] = pixel ;

Pour des raisons de sécurité paraît-il ? l'argument n'est pas valable car un processus est une zone de confinement et le crash de l'un de ses programmes ne doit en aucun cas mettre en péril le système qui révèlerait alors d"énormes failles. Dans mon programme, je dois pouvoir faire ce que je veux, même de le planter. C'était d'ailleurs le comportement voire la philosophie de l'hyperviseur IBM VM/CMS de gestion de machines virtuelles sur lequel j'ai travaillé pratiquement durant toute ma carrière.

Mais bon !... C'est comme ça.. Il faut faire avec ...

Bien cordialement.

Lou Papet

[Kannagi]

Je comprends le désir de performance des développeurs mais je ne comprends pas la censure qu'ils pratiquent. Il leur est extrêmement facile de placer un pixel dans une surface, il leur est tout autant de faire l'inverse. Ils ne doivent pas s'en priver. Pourquoi alors interdisent-ils d'en récupérer un sans avoir à faire l'arbre droit ? Personnellement, je n'ai jamais pratiquée cette censure dès lors qu'elle ne mettait pas en péril mon installation et qu'elle préservait les informations privées, bien au contraire, on avait tendance à me reprocher de trop en dire ce que ne m'enlevait absolument rien du tout.

Il faudrait que vous testiez au moins une fois OpenGL et vous comprendriez pourquoi l’accès au pixel n'est pas aisé , la SDL2 utilise la carte graphique pour faire du dessin , mais le buffer vidéo et du coup , plus compliqué a lire vu que ce n'est pas des octets dans votre ram , mais qu’il faut demander a la CG .
D'ailleurs si votre but et de faire une utilisation pixel par pixel manuellement alors j'ai envie de dire resté sur la 1.2 , sur la 2 faire cela vous aurez des performances catastrophiques (ou alors d'apprendre la programmation des shaders) .

[LittleWhite]

Les structures SDL_Renderer/SDL_Surface est autre sont cachés à l'utilisateur afin de respecter un principe de programmation qui est :

Faites en sorte qu'il soit impossible de mal utiliser la bibliothèque que vous proposez

Pour faire cela, les programmeurs C vont utiliser à outrance le compilateur, empêchant ainsi le programme de compiler lors d'une mauvaise utilisation. L'utilisateur n'a pas besoin d'avoir accès au contenu de ces structures car il y a des fonctions exposées pour cela et qui le feront mieux que l'utilisateur.

Notamment, dans les deux fonctions que vous montrez, elles sont relativement fausses car il manque le SDL_Lock...() de la surface. Car oui, il faut protéger les accès concurrents de la surface. Cette protection est correctement effectuée dans les fonctions de la SDL, mais si on laisse l'accès à l'utilisateur, alors il y a un risque qu'il l'utilise mal (car l'utilisateur fait toujours mal les choses ).

Il leur est extrêmement facile de placer un pixel dans une surface, il leur est tout autant de faire l'inverse.

Non. Malheureusement, non. L'opération de récupération des données GPU vers le CPU est lente. Si l'utilisateur lit les pixels un par un, sur ne serait-ce que 32x32 pixels, à chaque rendu ... alors le programme sera lent, très lent.
Récupérer l'image entière oui, mais cela reste lent. D'autant plus que rien ne vous garantit que l'image soit du format que vous pouvez utiliser. Si le format de pixel GPU n'est pas compatible/pas celui attendu, il faut faire une conversion.

[loupapet]

Bonjour,

Merci à LittleWhite et à Kannagi pour leur aide.

Je prends acte que ma demande n'est pas conforme à la philosophie unidirectionnelle de la SDL-2.0 surtout orientée performances, essentiellement pour les jeux si j'ai bien perçu le message.

Mais ce n'est pas grave du tout :

Je me résous donc à reprendre la solution originale que je ne voulais pas trop reconduire. Tout compte fait, elle est efficace et autrement plus simple. Elle est symétrique puisque le programme affiche lui-même la palette. Il est donc capable de retrouver la couleur du pixel indiqué par la souris sur la dite palette.

Je marque donc le sujet comme résolu sans insister davantage en trouvant cela un peu dommage.

Cordialement.
Lou Papet