SDL+OpenGL resize, handler des textures perduent

bonjour bonjour,
je fais un projet 3D dans le quel j'utilise SDL pour le fenêtrage et OpenGL... ben pour le reste !

j'ai mis en place la possibilité de resizé la fenêtre en settant le video mode de la sorte :

Code:

---

SDL_SetVideoMode(m_WinWidth, m_WinHeight, 32, SDL_OPENGL | (m_Fullscreen ? SDL_FULLSCREEN : 0) | SDL_RESIZABLE);

---

quand je redimensionne ma fenêtre, je catch l'event de resize

Code:

---

1 2 3 4 5 6

if (m_Event.type == SDL_VIDEORESIZE) { TRInst->m_WinWidth = m_Event.resize.w; TRInst->m_WinHeight = m_Event.resize.h; TRInst->InitGL(); //dans le quel il y a le SDL_SetVideoMode }

---

tout ceci marche à la perfection sur tout les PC sur lesquelles j'ai pu le tester
sauf mon eeePC
il se trouve que toute les textures (opengl) sont corrompu, ce qui m'impose de les décharger et les recharger lors d'un resize
cette situation n'arrivais que lorsque je passais du mode fenêtré à pleine écran, où la destruction de la fenêtre et des handler opengl semblais être inéluctable

pour le coups le fait que la config matériel de l'eeePC soit assez faiblarde doit y être pour quelque chose, mais je ne suis pas assez calé la dedans pour comprendre la raison, et encore moins comment le détecter au préalable pour ne recharger les textures que si besoin est.

pourriez vous m'éclairer ?

Bonjour,

Oui, il se peut qu'il existe une explication connue :D

OpenGL fonctionne par contexte ( enfin je ne sais pas si c'est le mot ). Lorsque l'on ouvre une fenêtre OpenGL, le contexte est crée. Lorsque nous fermons la fenêtre, le contexte est détruit.

Pour pouvoir utiliser les fonctions OpenGL, il faut qu'un contexte soit crée ( sinon OpenGL retourne une erreur bien spécifique ).

En fait, les ressources allouées dans chaque contexte ( texture IDs , Shader IDs et tout autre ID d'OpenGL ) ne peuvent fonctionner qu'avec ce contexte ( un peu comme une variable locale ).
Lorsque vous faites votre redimensionnement, vous recrée une fenêtre ( j'imagine que vous détruisez la précédente ..., pour éviter les fuites ), mais votre création de fenêtre crée un nouveau contexte, ce qui rend invalide tout les IDs alloués avant.

En fait, d'après moi, votre cas de cette perte en mode fenêtré et plein écran, me semble normal, mais lors d'un redimensionnement de fenêtre, il n'y a aucun besoin de reconstruire toute la fenêtre ... normalement, nous appelons juste un resize, qui change le viewport d'OpenGL ( et la perspective ).
Je vous conseille de jeter un coup d'oeil sur le code source SDL du tuto de NeHe n°6

Après, que cela arrive sur l'eeePC et pas sur les autres PCs, ce n'est pas parce que l'un est sur Linux, les autres sous Windows, car là, la gestion faite par la SDL, entre les deux systèmes peut légèrement différé ( voir encore le tuto N°6 de NeHe mais cette fois, le code source de base ( Windows donc ).

Donc, pour conclure, je ne vois pas du tout pourquoi votre fenêtre est reconstruite lors d'un redimensionnement, et elle ne devrait pas l'être.

bonjour LittleWhite,
dans le cas de figure où j'ai un resize que je catch par l'event, je rappelle SDL_SetVideoMode
je ne détruit pas l'ancienne fenêtre

je la détruit que lors du passage fullscreen <--> windowed
j'ai mentionné le cas de destruction des handlers dans cet unique cas

je dis aussi que pour pouvoir retrouver sur l'eeePC mes textures après redimensionnement il faut que je recrée les handlers (comme dans le cas de figure fullscreen <--> windowed qui est la cause d'une destruction de fenêtre)

et tout les PC tournent sous windows
les testes se sont portés sur :
windows xp home 32bit laptop dell -> OK
windows xp pro 32bit desktop -> OK
windows 7 pro 32bit desktop -> OK
windows 7 pro 64bit desktop -> OK
windows xp home 32bit eeePC -> FAIL

j'ai donc un cas étrange où mes handlers sont conservés sur un PC standard après un appel à SDL_SetVideoMode
et un cas où les handlers sont perdu sur un eeePC après ce même appel à SDL_SetVideoMode

d'où mon désarroi

C'est bizarre, on dirait que ça fait une sorte d'invalidation du device comme en directx...

Attendez, j'ai peut être mal compris une petite chose.

Vous m'avez montré ce code:

Code:

---

1 2 3 4 5 6 7

if (m_Event.type == SDL_VIDEORESIZE) { TRInst->m_WinWidth = m_Event.resize.w; TRInst->m_WinHeight = m_Event.resize.h; TRInst->InitGL(); //dans le quel il y a le SDL_SetVideoMode }

---

Qui est executé lors d'un redimensionnement. Vous me dites, que celui si appele SDL_SetVideoMode ( que moi je dis complètement inutile :p ).
D'après moi, le SDL_SetVideoMode, fait une destruction de la surface de la fenêtre est une reconstruction, mais en interne ( on est pas obligé de tout vous dire ). Je dis ça, car SDL ne gère qu'une et unique fenêtre...

Après avoir donné les différents systèmes d'exploitation ( je vous en remercie ) pourrait on avoir les différentes versions de SDL et OpenGL installé dessus? ( ou encore, les cartes graphiques et leur pilote ... notamment celle de l'eeePC, car, si c'est un Intel ( comme carte graphique ), bah, je dirai que le problème vient de là ( ils font des pilotes graphiques tout pourri ).
Mais au final, s'il y a bien recréation de fenêtre dans le SDL_SetVideoMode, d'après moi, ce serai le eeePC qui aurai un comportement le plus proche de la norme ... enfin d'après moi.

en ce qui concerne les versions de SDL et de OpenGL c'est la SDL 1.2.14, et OpenGL, c'est la version de base fournit avec windows

ensuite j'ai fait des testes et il se trouve que SDL_SetVideoMode me retourne le même pointeur après avoir été appelé une 2eme fois lors du resize.
de mon point de vue le resize ne nécessite pas de destruction de fenêtre, seul le fullscreen en demanderais.

les cartes graphiques sont de tout genre tout tarifs, ça va de la GeForce 8600GT à la Radeon HD 4850 X2 en passant par des Intel bas de gamme dans les eeePC (ps: j'ai testé sur un 2eme eeePC d'une année plus jeune et c'est le même problème, la config en est d'ailleurs très proche)

aux vues de tout cela, je ne suis pas contre employer la même méthode pour le resize que pour le fullscreen (cad: release des ressources graphique, destruction de la fenêtre, recréation de la fenêtre, rechargement des ressources graphique)
mais ça m'ennuie profondément

en lisant la documentation de SDL_SetVideoMode de mon point de vue il est nécessaire de le rappeler lors d'un resize, et, sauf erreur de ma part, il semble que la destruction de la fenêtre dans ce dernier cas soit évité

dans le cas où je me planterais, je serais ravie de savoir comment je peux faire pour resize une fenêtre SDL sans avoir a reload les ressources OpenGL

si je ne peux pas, alors comment faire pour savoir si un handler OpenGL est corrompu ?

si on ne peut pas le savoir, alors tant pis, je rechargerais à chaque fois, mais c'est très moche je trouve

Tout d'abord merci pour la page de documentation, car je n'utilise jamais la wiki ( mais la doc avec les bibliothèques ).
Bref, j'ai lu deux choses:

Pour le flag SDL_RESIZABLE

Citation:

---

Create a resizable window. When the window is resized by the user a SDL_VIDEORESIZE event is generated and SDL_SetVideoMode can be called again with the new size.

---

Qui veut dire:

Citation:

---

Creer une fenêtre redimensionnable. Lorsque la fenêtre est redimensionnée par l'utilisateur un évènement SDL_VIDEORESIZE est généré et SDL_SetVideoMode peut être appeler une nouvelle fois avec la nouvelle taille.

---

Alors, certes, ils parlent de SDL_SetVideoMode(). Certes ils disent que l'on peut le rappeler, mais il n'y aucune obligation ... ( ils auraient utilisé un 'must' ). Après, je n'ai jamais vraiment traité du redimensionnement, alors peut être que j'ai tort.

L'autre point à lire est:

Citation:

---

User note 2: Also note that, in Windows, setting the video mode resets the current OpenGL context. You must execute again the OpenGL initialization code (set the clear color or the shade model, or reload textures, for example) after calling SDL_SetVideoMode. In Linux, however, it works fine, and the initialization code only needs to be executed after the first call to SDL_SetVideoMode (although there is no harm in executing the initialization code after each call to SDL_SetVideoMode, for example for a multiplatform application).

---

Citation:

---

Note utilisateur 2: Remarquez que, avec Windows, définir le mode video réinitialise le contexte courant d'OpenGL. Vous devez exécuté encore une fois le code d'initialisation d'OpenGL ( définir la couleur de nettoyage ou les shaders, ou recharger les textures, par exemple ) après avoir appeler SDL_SetVideoMode. Sous Linux, toutefois, cela fonctionne, et le code d'initialisation n'a besoin d'être exécuté qu'après le premier appel à SDL_SetVideoMode ( bien que, il n'y a aucun mal à exécuté le code d'initialisation après chaque appel à SDL_SetVideoMode, par exemple pour les application multiplateforme ).

---

Donc, l'histoire est, que certes vous avez eu de la chance, le context n'est pas toujours perdu pour vous, mais, le pilote graphique intel ( qui est un pilote moins performant que les autres en fait ( je ne dis pas ça que pour troller ... ) ) à plus de problème à suivre la norme ... du coup , il peut poser des problèmes.

Maintenant, pour OpenGL, je ne sais plus s'il y a une fonction du genre GL_isTexture() un truc du genre, pour vérifié si l'ID est bon. Pour les shaders il y a une fonction de ce type. Je vous laisse le soin de regarder dans la documentation d'OpenGL.

Je suis entièrement d'accord avec vous, que le rechargement des ressources OpenGL est gênant ( lent ... ) et ... pour le moment, je vous déconseille toujours de faire ce SDL_SetVideoMode après le changement de taille de la fenêtre. Mais, pour cela, comme je n'en suis pas sur, je vais faire un programme de test chez moi ;) Et je reviens pour dire si cela fonctionne sans ;).

Finalement, j'ai fait le test avec le SDL_VIDEORESIZE, et je comprends mieux la nécessité de l'appel à SDL_SetVideoMode() après la redimension.
Du coup, on ne peut pas y échapper...
Du coup, je pense qu'il est nécessaire de recharger à chaque fois vos ressources. En fait, je dirai même, que sur ce point là, la SDL c'est tout pourri...

bonjour,
il se trouve qu'OpenGL fournit une fonction

Code:

---

GLboolean glIsTexture( GLuint texture);

---

qui retourne si le handler "texture" est bien une texture d'OpenGL.

j'ai fait le teste en ajoutant une fonction de vérification après le resize dans mon code et, sous l'eeePC, la fonction glIsTexture renvoi FALSE, pas sous les autres archi.

de ce fait une simple fonction de vérification sur chaque handler, qui recharge les textures si elles sont corrompus après resize, fait l'affaire ;)

merci pour cet échange instructif LittleWhite, à bientôt pour de nouvelles interrogations ;)