Initialiser opengl avant d'instancier une surface.

Version imprimable

10/09/2007, 10h11
valefor

Initialiser opengl avant d'instancier une surface.

Bonjour,.

Je souhaite (peut-être est-ce illégitime ?) pouvoir appeler des fonction opengl avant d'avoir fait un setvideomode. Or cela ne semble pas fonctionner, sans doute a cause du fait que opengl n'est initialisé que lors du setvideomode.

Serait-ce possible d'initialiser opengl avant d'avoir fait appel à SDL_SetVideoMode (pour charger des textures etc par exemple) ?

Merci.
10/09/2007, 10h24
Laurent Gomila

Non, à ma connaissance SDL ne permet pas ça.
10/09/2007, 15h57
fearyourself

Citation:

Envoyé par valefor

Serait-ce possible d'initialiser opengl avant d'avoir fait appel à SDL_SetVideoMode (pour charger des textures etc par exemple) ?

Non ce n'est pas possible et je ne vois pas l'intéret. Tu peux charger les textures une fois cet appel fait.

Jc
10/09/2007, 17h07
valefor
Je voulais faire cela car j'ai grosso modo ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 SDL_SetVideoMode() /* initialisation */ while(1) { if(refenetrage) { SDL_SetVideoMode() } dessine(); } /* terminaison */
J'aurai voulu factoriser les deux SDL_SetVideoMode, en ne laissant que le second, et forcer le refenetrage lors de la première boucle.

Mais il n'y a pas d'obligations... donc je vais faire autrement.
10/09/2007, 17h17
Laurent Gomila

De toute façon, lors du second SetVideoMode il faudra quand même recréer toutes tes ressources OpenGL, car le contexte sera détruit et recréé par SDL.
11/09/2007, 10h42
valefor

D'ailleurs dans les "contre" utiliser sdl pour fenêtrer opengl on pourra noter cet inconvénient : "A chaque re-dimensionnement de fenêtre il faut tout recréer"... C'est pas rien comme contrainte...

EDIT : il semble qu'en réalité il y ai bien des plateformes sur lesquelles il faille ré-initialiser le contexte (windows), et d'autres non. Mais comme ce n'est pas portable de ne pas réinitialiser il faut le faire... Je suis très décu et m'en vais trouver autre chose que sdl.
11/09/2007, 11h16
fearyourself

Citation:

Envoyé par valefor

D'ailleurs dans les "contre" utiliser sdl pour fenêtrer opengl on pourra noter cet inconvénient : "A chaque re-dimensionnement de fenêtre il faut tout recréer"... C'est pas rien comme contrainte...

Pas vraiment, si le code est propre, cela ne demande pas beaucoup de modifications du code.

Citation:

EDIT : il semble qu'en réalité il y ai bien des plateformes sur lesquelles il faille ré-initialiser le contexte (windows), et d'autres non. Mais comme ce n'est pas portable de ne pas réinitialiser il faut le faire... Je suis très décu et m'en vais trouver autre chose que sdl.

Bonne chance, je pense que ce problème n'existe pas sous Glut par contre, utiliser Glut à la place de la SDL...

Jc
11/09/2007, 11h38
Laurent Gomila

Citation:

EDIT : il semble qu'en réalité il y ai bien des plateformes sur lesquelles il faille ré-initialiser le contexte (windows), et d'autres non. Mais comme ce n'est pas portable de ne pas réinitialiser il faut le faire... Je suis très décu et m'en vais trouver autre chose que sdl.

SFML, si tu fais du C++ ;)
11/09/2007, 15h05
valefor

Code:

Pas vraiment, si le code est propre, cela ne demande pas beaucoup de modifications du code.

Ce n'est pas de le coder qui me gène, mais de le concevoir. Pour moi, mon programme devait avoir une phase d'init (avec des accès aux fichiers, des micmacs éventuels, une grosse occupation mémoire temporaire, etc...) et une phase de run.

J'aurai voulu limiter les trucs qui plombent les performances en run, voila tout (même, si je vous l'accorde, un re-dimensionnement de fenêtre est un cas rare).

Merci pour le lien vers SFML, je ne connaissais pas du tout.
11/09/2007, 15h09
fearyourself

Citation:

Envoyé par valefor

Ce n'est pas de le coder qui me gène, mais de le concevoir. Pour moi, mon programme devait avoir une phase d'init (avec des accès aux fichiers, des micmacs éventuels, une grosse occupation mémoire temporaire, etc...) et une phase de run.

J'aurai voulu limiter les trucs qui plombent les performances en run, voila tout (même, si je vous l'accorde, un re-dimensionnement de fenêtre est un cas rare).

C'est impossible de tout séparer pour de bon. Dans un grand projet, il est impensable de charger toutes les textures, sons, niveaux au début du programme. Il faut le faire progressivement dépendant des besoins actuels du programme.

Du coup, le code qui gére les ressources peut, de facon transparente, gérer la création d'un nouveau contexte.

Jc