Version imprimable
Bonojur,
je voulais savoir s'il est possible d'avoir un RenderContext valide pour GL3 en utilisant SFML.
Sinon, à quel endroit dois-je modifier le code?
En fait, c'est relativement d'obtenir un contexte valide sous SDL (GLUT, GLFW, ... pas encore essayés), mais j'aimerais utiliser SFML pour mon projet, d'où la question.
C'est implémenté depuis peu dans la branche SFML 2.0, que tu peux récupérer via SVN (ça ne marche que sous Windows pour l'instant).
Si pour une raison quelconque tu ne peux pas, je te montrerai le code qu'il faut ajouter.
Le code dont tu parles, c'est le code avec wglCreateContextAttribsARB(dc, attribs); ?
Celui-là, je l'ai. (J'ai créé un petit bout de code pour contexte GL3 en utilisant SDL, ca n'a pas vraiment été un problème).
Mais merci pour la réponse, je ferais un checkout ce soir.
Sinon, est-ce que les fonctions GL3 sont disponibles à partir d'un en-tête chez toi ou est-ce que je dois me les initialiser moi-même (genre avec glew) ?
Alors impeccable, c'est tout ce qu'il faut.Citation:
Le code dont tu parles, c'est le code avec wglCreateContextAttribsARB(dc, attribs); ?
Celui-là, je l'ai
SFML ne gère pas les extensions, il faut effectivement utiliser GLEW.Citation:
Sinon, est-ce que les fonctions GL3 sont disponibles à partir d'un en-tête chez toi ou est-ce que je dois me les initialiser moi-même (genre avec glew) ?
tiens, j'ai remarqué que ton contexte GL n'est pas "forward compatible", c'est-à-dire, sans les fonctions obsolètes. Je me doute que tu t'en sers pour SFML et que ca va pas être enlevé sous peu, si?
Sinon, tu saurais pas s'il y a un header ne contenant plus que les fonctions GL3, histoire qu'utiliser des fonctions obsolètes me donne des erreurs de compilation et non pas des mauvaises surprises dans qqs mois quand la cmopatibilité sera effectivement brisée par le driver?
(Je sais que je peux m'en construire un tout seul, soit en utilisant le make custom de glew, soit en y allant à la main, mais c'est prenant de temps et de tête que de chercher ces fonctions ou extensions...)
J'ai pas compris :aie:Citation:
tiens, j'ai remarqué que ton contexte GL n'est pas "forward compatible", c'est-à-dire, sans les fonctions obsolètes. Je me doute que tu t'en sers pour SFML et que ca va pas être enlevé sous peu, si?
Non, sorry.Citation:
Sinon, tu saurais pas s'il y a un header ne contenant plus que les fonctions GL3, histoire qu'utiliser des fonctions obsolètes me donne des erreurs de compilation et non pas des mauvaises surprises dans qqs mois quand la cmopatibilité sera effectivement brisée par le driver?
C'est ce que je voulais dire, c'est que ton contexte GL n'est pas celui qui supprime les fonctions obsolètes (faut passer 2 autres paramètres à wglCreateContextAttribsARB() pour cela*).
Et je pense que tu utilises des fonctionalités niveau GL1.x ou 2.x pour SFML, notamment pour l'interface utilisateur et tout ca. Donc, utiliser un contexte 3.x pur pourrait peut-être te poser problème.
* et prier pour que le driver enlève effectivement ces fonctions (ce qui n'est pas encore le cas chez nVidia).
Ok je vois, merci pour l'info. Tant que je ne me serai pas débarassé des fonctions obsolètes il faudra donc que j'évite de laisser la possibilité de créer des contextes 3.0 purs.
Oui, enfin ca fonctionnera quand même si tu mets le "forward compatible bit" pour l'instant, mais uniquement jusqu'à ce que NV corrige ce bug.
-> http://www.gamedev.net/community/for...opic_id=512890
(ma source)
Voilà.Code:
2
3
4
5
6
7
En fait, je ne sais pas comment tu dessines les rectangles de l'interface (pour les sprites, tout ca), mais je suppose que tu utilises la facon la plus facile: le pipeline fixe de l'openGL classique. Or cette fonctionalité est celle qui jarte(ra à un moment ou autre de facon définitive), d'où le problème.
Tu pourrais aussi me rassurer et dire que SFML est entièrement GL 2.1, auquel cas porter vers 3.x ne sera pas trop difficile.
Enfin, si je dis ca, c'est parce que je suis en train de créer mon petit moteur GL 3.x pur et que j'aimerais avoir des erreurs à la compilation et non à l'execution si j'utilise des choses obsolètes...
SFML utilise les fonctions les plus au ras des paquerettes d'OpenGL 1.x : le rendu immédiat (glBegin / glVertex / glEnd). Ca peut paraître idiot, mais c'est ce qu'il y a de mieux pour du rendu de quad complétement dissocié (i.e. pas de batching).
Enfin bon un de ces jours il faudra que je fasse évoluer le code de rendu, pas le choix.
Je m'en doutais. C'est pour ca que SFML est portable vers GL ES 1.1 (iPhone).
Du coup, si j'utilise un contexte "exclusif" GL 3.x, ca risquera de briser un peu tout l'appli, non?
Je ne me suis pas trop penché sur le sujet, mais vu ce que tu dis il y a des chances oui. De toute façon la prochaine grosse étape après SFML 2.0 sera certainement une refonte totale du code de rendu, afin d'être compatible avec tous les back-end OpenGL à la mode (GL ES 2.x, GL 3.x, ...).
Tu vas t'amuser avec les différentes spec des shaders :aie: (GLSL 1.20 différent de 1.30 différent de 1.40).
Je te conseille de viser la compatibilité avec GL3.0, vu que GL ES 2.0 et ES 3.0 (prevu pour 2010) suivent la même route (avec juste quelques fonctions en moins, je crois).
Puis... iPhone HD, Palm Pre, ya pas mal de plateformes pour ES 2.0 en perspective..
Bonjour Laurent , tout d'abord permet moi de te félicité pour cette librairie.
je développe en amateur sous Linux , et dernièrement je m'intéresse à l' OpenGL 3 de très près , n'ayant ni l'envie ni le temps de manipulé X11 pour avoir un contexte OpenGL 3 , je voulais savoir se qu'il en était de la version 2.0 pour Linux.
Merci.
La gestion des contextes OpenGL 3.0 n'est toujours pas implémentée sous Linux, mais ça peut se faire rapidement. Il faut juste que je trouve comment faire (ça ne devrait pas être très différent de la version Windows) ;)
Bonjour monsieur Gomila. Savez-vous quand sera disponible la version officielle de SFML 2.0 (la version actuelle est 1.5 je crois...). Conservera-t-elle la possibilité de créer un contexte OpenGL 3.x. Il me semble qu'actuellement, la version SVN crée automatiquement un contexte OpenGL 3.0 (si les drivers le permettent évidemment). C'est bien parce que c'est transparent pour l'utilisateur, mais ne serait-il pas possible de proposer un argument optionnel (ou pas optionnel d'ailleurs, j'en sais rien!...) afin de choisir la version du contexte OpenGL créé.
Bon ben en fait voilà, c'est fait (dans la branche sfml2). Si tu as l'occasion de tester n'hésite pas, car chez moi je ne peux pas le faire ;)Citation:
La gestion des contextes OpenGL 3.0 n'est toujours pas implémentée sous Linux, mais ça peut se faire rapidement
Non, mais c'est pas encore pour tout de suite ;)Citation:
Savez-vous quand sera disponible la version officielle de SFML 2.0
Il n'y a que dans SFML 2 que tu peux créer un contexte 3.0. Les versions 1.x ne le feront jamais.Citation:
Conservera-t-elle la possibilité de créer un contexte OpenGL 3.x
Ca peut se faire oui. Il faudrait d'abord voir quel intérêt cela aurait. Etant donné que je crée des contextes compatibles avec OpenGL < 3.0, ça n'a normalement aucun effet de bord.Citation:
Il me semble qu'actuellement, la version SVN crée automatiquement un contexte OpenGL 3.0 (si les drivers le permettent évidemment). C'est bien parce que c'est transparent pour l'utilisateur, mais ne serait-il pas possible de proposer un argument optionnel (ou pas optionnel d'ailleurs, j'en sais rien!...) afin de choisir la version du contexte OpenGL créé
Merci pour ces réponses.
Je tâtonne la SFML depuis 2 / 3 jours , c'est super.
étant aussi utilisateur du Purebasic je pense faire un binding de la librairie , cela intéressera certainement cette petite équipe qui produit pas mal de petit jeu : BGames
Mais avant de me lancer dedans , est ce que la SFML 2.0 va connaître une refonte au point de supprimer ou de renommé des fonctions déjà existante ?
Oui, malheureusement. Il est donc hasardeux de commencer un binding tout de suite, à moins que tu ne suives les modifications au fur et à mesure.Citation:
Mais avant de me lancer dedans , est ce que la SFML 2.0 va connaître une refonte au point de supprimer ou de renommé des fonctions déjà existante ?
Merci Laurent , je vais attendre patiemment la 2.0.
j'espère que cette lib va prendre de plus en plus d'ampleur ! :ccool: