OpenGL 2, 3, 4? Ou DirectX?

Hoy! Ma soif de savoir fini par me faire lâcher la prise ici. :p

Je développe en ce moment un shoot'em up 2D, en utilisant SFML. SFML ajoute une couche pour utiliser plus facilement OpenGL 2.0. Mon soucis se présente en partie dans la limitation de la taille des textures chargé dans la mémoire graphique et de violentes saccades lors de l'utilisation de la vertical sync.

De fait, j'aurai aimé avoir des informations sur les versions 3.0 et 4.0 d'OpenGL, quelles sont leurs différences fondamentales avec la 2.0, et si utiliser ces versions peuvent me permettre de résoudre mon problème.

Aussi, j'hésite fortement à continuer d'utiliser OpenGL, ou de passer sur DirectX pour mon jeux 2D. Je ne compte pas vraiment profiter de la portabilité, mon jeu sera principalement sur Windows. Quel API est-il plus futé de prendre pour moi?

Citation:

---

Envoyé par Spidyy

Hoy! Ma soif de savoir fini par me faire lâcher la prise ici. :p

Je développe en ce moment un shoot'em up 2D, en utilisant SFML. SFML ajoute une couche pour utiliser plus facilement OpenGL 2.0. Mon soucis se présente en partie dans la limitation de la taille des textures chargé dans la mémoire graphique et de violentes saccades lors de l'utilisation de la vertical sync.

De fait, j'aurai aimé avoir des informations sur les versions 3.0 et 4.0 d'OpenGL, quelles sont leurs différences fondamentales avec la 2.0, et si utiliser ces versions peuvent me permettre de résoudre mon problème.

Aussi, j'hésite fortement à continuer d'utiliser OpenGL, ou de passer sur DirectX, pour mon jeux 2D. Je ne compte pas vraiment profiter de la portabilité, mon jeu sera principalement sur Windows. Quel API est-il plus futé de prendre pour moi?

---

Personnellement je préfère OpenGL de loin à DirectX, mais c'est plus une question de goût que de spécifications techniques.

OpenGL est une API contextuelle à plat, DirectX est tout objet

pour ce qui est des performances, c'est de toute façon la carte graphique qui bosse, et l'un comme l'autre permettent d'obtenir ce qu'on veux.

Les seuls projets où j'ai préféré DirectX étaient pour un accès direct à la mémoire vidéo sous DirectDraw, je n'avais pas besoin des fonctions graphiques, tout le rendu étant fait en soft.

C'est aussi sque j'en ai entendu en cherchant sur le net. :p

Mais au niveau des différences OpenGL 2.0, 3.0 et 4.0?

les ajouts de opengl 3 et 4 c'est surtout les nouveaux étages de shaders, comme directx 10 et 11 c'est à dire :

- geometry shader
- tesselation (hull, domain, tesselator, pour reprendre le vocabulaire dx)

après les différences entre les eux, c'est surtout une habitude de programmation.

par contre directx c'est des objets COM, pas objet au sens c++.

Pas des choses qui me servirons je pense donc.

Le problème qui me bloque pas mal, c'est la taille des texture. Dans la bibliothèque que j'utilise, les textures sont limité en taille suivant la carte graphique. Les texture au delà de 1024*1024 ont du mal à passer chez certains.

Mon soucis, c'est qu'en terme de jeu 2D, j'ai une grosse utilitée pour les texture très large, d'autant plus que j'y applique un résolution plutôt élevée. Y a-t-il moyen de contourner ou d'éviter ce problème avec OpenGL?

Si non, Y-a-il un moyen de contourner ou d'éviter le problème cette fois-ci avec DirectX?

à part passer à une version supérieure d'opengl (3 ou 4) ou aller sur dx (10 ou 11) je ne pense pas que tu puisses d'affranchir de ta limite actuelle.

il faut bien penser que directx n'est qu'un sous ensemble de fonctionnalités de opengl mais ces fonctionnalités sont communes à toutes les cg compatibles.

directx et opengl ont le même (presque) socle commun, mais opengl autorise l'utilisation de fonctionnalités dépendantes du constructeur.

donc si tu as une limite avec opengl, tu as toutes les chances de retrouver la même limite avec une version de dx équivalente, voir une limite encore plus stricte.

Bon, ça veut tout dire, jvais partir sur OpenGL 3.0 minimum. :p

Merci pour toutes ces indications!

Pourquoi utiliser des images aussi grosses ? Etant donné que c'est de la 2D tu peux très facilement les découper en plus petit blocs et bidouiller un peu au moment du rendu.
Ce qui est sur, c'est que passer a une version plus récente d'OpenGL (ou directx) ne réglera en aucun cas ton problème: ceux qui ne peuvent pas avoir de textures plus larges que 1024*1024 n'ont probablement pas une carte qui supporte OpenGL3/D3D10.

Pour certains background. Je n'ai pas envi d'arrondir les coordonnée pour garder le côté très smoothé des déplacements, mais si je découpe l'image, avec le déplacement, on voit la séparation. D'où le fais de l'avoir le background en entier.

Et le background s'étend sur 2000 ou 3000 pixels pour l'instant. :x

Bonjour,

Je suis pleinement d'accord avec math_lab !

Votre problème est loin d'être un problème sur OpenGL / DirectX ou encore SFML, mais surement de votre programme.
Effectivement, sur certaines cartes graphiques des textures supérieur à 1024x1024 ... peuvent ne pas passer (j'ose croire que c'est sur les vieilles cartes (disons 5 ans)).
Les textures 4096x4096 sont maintenant supporté assez couramment.
Après, il y a aussi le fait qu'il faut que les textures soit avec des dimensions utilisant des puissances de deux. Car, ils ont beau dire supporter les textures NPOT (Not Power of Two) mais c'est lent, souvent un peu lamentable comme support :( .

Citation:

---

Et le background s'étend sur 2000 ou 3000

---

Oui ... alors là ... il y a un autre point qui est à voir. Si vous ne voyez pas une partie de la carte (ou autre) (car j'imagine que vous n'avez pas une fenêtre de 2000 x 3000), alors ne dessinez pas. Il ne sert à rien d'essayer d'afficher des trucs que l'on ne verra pas :p (cela allégera le travail coté API et carte graphique)

Avec mes méthodes actuelles, je découpe le background en images de 256*256 pixels. Seul les images, affichées via des quads, qui sont visible à l'écran sont dessinés.

L'idéal pour éviter ça serait de pouvoir stocker le background en mémoire en conservant sa grande taille, et en afficher qu'un morceau, via un quad qui fait pile la taille de la zone.

Le problème de la première solution, c'est que je ne peux pas utiliser des positions en entiers, sinon on voit les séparations entre chaque morceau du background, ça fait une grille très moche à l'écran. :( D'où mon besoin de stocker l'image en un seul morceau.

Mais si c'est pas possible, va me falloir revoir mes standard. (Baisse de résolution?)

Citation:

---

Envoyé par Spidyy

Le problème de la première solution, c'est que je ne peux pas utiliser des positions en entiers, sinon on voit les séparations entre chaque morceau du background, ça fait une grille très moche à l'écran. :( D'où mon besoin de stocker l'image en un seul morceau.

---

problème de filtrage sur le bord des triangles? GL_CLAMP_TO_EDGE?

les positions en entier ne devraient pas poser de problème, à moins que 2 tuiles adjacentes ne soient pas arrondis pareil?

Citation:

---

De fait, j'aurai aimé avoir des informations sur les versions 3.0 et 4.0 d'OpenGL, quelles sont leurs différences fondamentales avec la 2.0, et si utiliser ces versions peuvent me permettre de résoudre mon problème.

---

Absolument pas, par contre ça t'en rajoutera sans doute beaucoup.

Citation:

---

Aussi, j'hésite fortement à continuer d'utiliser OpenGL, ou de passer sur DirectX pour mon jeux 2D. Je ne compte pas vraiment profiter de la portabilité, mon jeu sera principalement sur Windows. Quel API est-il plus futé de prendre pour moi?

---

Je dirais DirectX 9. Si tu utilise OpenGL 2.0 alors ton jeu ne marchera tout simplement pas partout.

Tu utilise les shaders ? => tu perds la compat avec pas mal de cartes Intel
Tu utilise les texture NPOT => tu perds la compat avec pas mal de cartes ATI

Es-tu prêt a faire un chemin de rendu "moche" qui marche avec OpenGL 1.4 voire moins ? Non ? Alors prend DirectX.


Edit: ah ouais tu pars avec OpenGL 3.0 minimum. Ca veut dire que tu demande a tous tes utilisateurs d'avoir des drivers de 2010, et au moins une Geforce 8400GS+ ou ATI HD 2400. Je ne sais pas pour les cartes Intel mais si tu ne testes pas sur un vendor, alors ça ne marche probablement pas.

Citation:

---

Envoyé par ponce

Tu utilise les shaders ? => tu perds la compat avec pas mal de cartes Intel
Tu utilise les texture NPOT => tu perds la compat avec pas mal de cartes ATI

---

Pour le NPOT je suis d'accord.
Pour la compatibilite Intel ... je suis un peu etonne. Certes leurs cartes sont moins puissantes, mais si c'est les puces SGX ... c'est juste que les shaders sont beaucoup plus stricte (et en fait, plus proche de la specification) que les trucs de NVidia / AMD.
Et cela est a cause, que les client de Imaginations Technologies l'ont demande...

Pour les NpoT, a moins d'avoir une carte préhistorique (genre pas de shaders), ça devrait pas poser de problèmes. Il faut juste utiliser l'extension TEXTURE_RECTANGLE_ARB au lieu de TEXTURE_2D. Sur une Radeon X1300 (pas tout neuf, quand même), ça passe impec.
Et pour les shaders, je rejoins LittleWhite. N'importe quelle carte Intel trouvable de nos jours devrait supporter les shaders. Et passer sous DirectX ne changera rien au problème, vu qu'au final, c'est toujours la carte qui pose problème (ou éventuellement des vieux drivers foireux :P), mais jamais l'API.

Citation:

---

Envoyé par math_lab

Pour les NpoT, a moins d'avoir une carte préhistorique (genre pas de shaders), ça devrait pas poser de problèmes. Il faut juste utiliser l'extension TEXTURE_RECTANGLE_ARB au lieu de TEXTURE_2D. Sur une Radeon X1300 (pas tout neuf, quand même), ça passe impec.
Et pour les shaders, je rejoins LittleWhite. N'importe quelle carte Intel trouvable de nos jours devrait supporter les shaders. Et passer sous DirectX ne changera rien au problème, vu qu'au final, c'est toujours la carte qui pose problème (ou éventuellement des vieux drivers foireux :P), mais jamais l'API.

---

Pour les NPOT le probleme n'est pas trop de savoir si cela est ou non dans la carte graphique ... c'est juste que le support est souvent plus lent que pour des textures normales et quelques fois avec de la corruption dans l'affichage

Bonjour,

je lutte depuis pas mal d'années avec la compatibilité OpenGL, en particulier sur les cartes Intel. Ce que je peux dire c'est que je n'ai aucune confiance en leurs drivers...

Le problème c'est que sur un ordi Dell par exemple, on ne peut installer que les drivers dell, qui suivent rarement les mises à jour des drivers Intel, ATI ou Nvidia. Avec ATI et Nvidia c'est moins un problème, car leurs drivers sont en général moins buggés donc il n'est pas absolument nécessaire d'avoir la dernière version. Avec Intel c'est une autre histoire...

Bref, en général quand mon soft doit tourner partout, je passe en rendu software (le driver OpenGL1.1 de Windows). C'est moche, c'est lent, mais ca tourne, et si le client veut mieux, soit il met à jour ses drivers, soit il achète une carte ATI et Intel (de nos jours une carte compatible OpenGL 2.0 se trouve à moins de 50€...)

Concernant les textures NPOT, je dirais que c'est un faux problème, j'utilise gluScaleImage pour redimensionner toutes les textures que je passe et ca marche sans problème, y compris sur Intel, et aussi en rendu software.

A partir du moment où tu fournis la possibilité de faire un rendu software et que du coup ton programme ne crashe pas, c'est à l'utilisateur de se bouger pour mettre à jour ses drivers / acheter une carte si il veut plus de perfs ou un meilleur rendu, et tu te décharges d'une grosse responsabilité.

J'imagine que la compatibilité DirectX est mieux faite mais comme dit, même avec OpenGL tu peux t'en sortir. Pour le reste je n'ai pas d'avis car je n'ai jamais utilisé directX.

Wahou, j'ai bien fais de lancer le sujet.

Donc OpenGL 2.0 suffisant? J'utilise en effet les shaders, des shaders tout simple (pas de grosse fonctions, juste les opérateurs standard, et ptet du cos()), et beaucoup d'image NPOT.

En effet pour deux textures l'une à côté de l'autre, avec des coordonnées arrondies, ça marche bien, mais je cherche justement à éviter ça. Jvais tester le GL_CLAMP_TO_EDGE. :p

Mon autre soucis, c'est la VSync, là où les carte NVidia gère très bien la VSync sous OpenGL 2, les carte ATI massacre complètement l'affichage, causant des saccade dans le programme et à l'extérieur du programme. C'est une des raisons qui me pousserait à passer sur DirectX.

Essaie de mettre les pilotes de la carte graphique. Au boulot, j'avais un vieux pilote qui me faisait tourner un tas de trucs en software sans me le dire (genre le sampling des textures, ce qui fait très mal aux perfs), et quand j'ai mis a jour, je me suis retrouvé avec quelque chose de bien plus correct.
Encore une fois, si ca merde sous OpenGL, ça risque fort de merder sous DirectX (pour peu que les deux soient a jour, évidemment).

Par contre, j'ai toujours pas compris ton histoire d'arrondi... Si tu bosses sous une API 3D, je suppose que tu dessines avec des quads, et donc dans un espace continu (donc tes coordonnées peuvent être des floats). Pourquoi est-ce que tu tiens absolument a arrondir tes coordonnees ? OpenGL sait très bien gérer les points entre les pixels de tes textures (ça s'appelle le sampling).

Oui pardon, j'utilise SFML qui est une API 2D utilisant OpenGL, donc les coordonnées des vertex sont grosso modo ceux des pixels, d'où le fait de les arrondir pour que ça loge, mais je ne veux justement pas les arrondir.

Mon principal soucis c'est de pouvoir poser côte à côte mes quads sans que la séparation se voit et sans utiliser les arrondie.

J'extrapole un peu mais c'est pour son bien, ca me semble une très mauvaise idée de demander OpenGL 3 à ses utilisateurs. Si ton jeu est joué tu va avoir 50% des gens qui se plaignent en continu, et ce sera trop tard/trop compliqué pour en changer.

Citation:

---

Pour les NpoT, a moins d'avoir une carte préhistorique (genre pas de shaders), ça devrait pas poser de problèmes. Il faut juste utiliser l'extension TEXTURE_RECTANGLE_ARB au lieu de TEXTURE_2D. Sur une Radeon X1300 (pas tout neuf, quand même), ça passe impec.

---

Supposons que ca marche : tu ne peux plus utiliser le filtrage alors que tes texture NPOT sont probablement utilisée pour ton post-processing, c'est dommage. J'avais eu des problèmes de NPOT avec une X700 et il avait fallu tout passer en POT.

Après les anglo-saxons ont un terme pour ça : YMMV

Après bidouillage, je me retrouve avec un fonctionnement comme je l'entendais, pas de séparation visible, les déplacements fluides... Je pige vraiment rien au pourquoi du comment. :(

J'avais activé le GL_TEXTURE_WRAP, en essayant avec GL_CLAMP et GL_REPEAT, ça me faisait les séparations. J'ai remis sans TextureWrap, ça marche tout bien. Brayf.

et le clamp to edge?

En fait ma version du gl.h ne permet pas le GL_CLAMP_TO_EDGE, je n'ai que le GL_CLAMP et GL_REPEAT. :/

arf, j'ai eu le même soucis à une époque, regarde du coté de glext.h si mes souvenirs sont bons, c'est ce que j'avais utilisé à une époque parce que lors d'un affichage de skybox, on voyait les arêtes du cube.

En fait ça marche même sans le GL_TEXTURE_WRAP là. :p Donc jvais pas toucher d'avantage.

Bon en fait le GL_CLAMP_TO_EDGE est utilisé par défaut dans la SFML, ça explique que ça marche. :]