Quelle (s) version (s) d'OpenGL apprendre et / ou utiliser?

16

Donc, je suis nouveau sur OpenGL ... J'ai une connaissance générale de la programmation de jeux mais peu d'expérience pratique.

J'ai cherché dans divers articles et livres et j'ai essayé de plonger dans OpenGL, mais j'ai trouvé les différentes versions et les anciennes vs les nouvelles façons de faire les choses confuses.

Je suppose que ma première question est de savoir si quelqu'un connaît des chiffres sur les pourcentages de joueurs qui peuvent exécuter chaque version d'OpenGL. Quelle est la part de marché? 2.x, 3.x, 4.x ...

J'ai examiné les exigences de Half Life 2 depuis que je sais que Valve l'a mis à jour avec OpenGL pour fonctionner sur Mac et je sais qu'ils essaient généralement de toucher une base d'utilisateurs très large, et ils disent un minimum de GeForce 8 Series. J'ai regardé le 8800 GT sur le site Web de Nvidia et il a répertorié la prise en charge d'OpenGL 2.1. Ce qui, peut-être que je me trompe, me semble ancien puisqu'il y a déjà 4.x. J'ai recherché un pilote pour 8800GT et il dit qu'il prend en charge 4.2! Un peu de divergence là-bas, lol.

J'ai également lu des choses comme XP ne prend en charge que jusqu'à une certaine version, ou OS X ne prend en charge que 3.2, ou toutes sortes d'autres choses. Dans l'ensemble, je suis simplement confus quant au niveau de prise en charge des différentes versions et à la version à apprendre / utiliser.

Je recherche également des ressources d'apprentissage. Jusqu'à présent, mes résultats de recherche m'ont montré la OpenGL SuperBible. La 4e édition a d'excellentes critiques sur Amazon, mais elle enseigne 2.1. La 5ème édition enseigne 3.3 et il y a quelques choses dans les critiques qui mentionnent que la 4ème édition est meilleure et que la 5ème édition n'enseigne pas correctement les nouvelles fonctionnalités ou quelque chose? Fondamentalement, même dans le matériel d'apprentissage, je constate des écarts et je ne sais même pas par où commencer.

D'après ce que je comprends, 3.x a commencé une toute nouvelle façon de faire les choses et j'ai lu dans divers articles et critiques que vous voulez "rester à l'écart des fonctionnalités obsolètes comme glBegin (), glEnd ()" et pourtant beaucoup de livres et des tutoriels que j'ai vus utiliser cette méthode. J'ai vu des gens dire que, fondamentalement, la nouvelle façon de faire les choses est plus compliquée mais que l'ancienne est mauvaise>.>

Juste une petite note, personnellement, je sais que j'ai encore beaucoup à apprendre avant, mais je suis intéressé par la tessellation; donc je suppose que cela entre également en ligne de compte, parce que, pour autant que je sache, ce n'est qu'en 4.x?

[juste btw, mon bureau prend en charge 4.2]

Kenmore
la source
Cette question (sur Stack Overflow) semble être un doublon: stackoverflow.com/questions/6823371/…
Anderson Green

Réponses:

21

Si vous vous interrogez sur la couverture OpenGL, le Steam Hardware Survey est un bon point de départ.

http://store.steampowered.com/hwsurvey?platform=pc

Malheureusement, il semble être en panne en ce moment et il n'affiche aucune statistique pour les cartes vidéo. : \

J'ai également lu des choses comme XP ne prend en charge qu'une certaine version

DirectX 9 est comparable à OpenGL 2.1, DirectX 10 à OpenGL 3.0 et DirectX 11 à OpenGL 4.0. C'est de là que vient la confusion.

XP prend en charge toutes les versions d'OpenGL, mais il ne prend pas en charge DirectX 10 ou version ultérieure. C'est ainsi que Microsoft voulait forcer les gens à passer à Vista, mais cela n'a pas très bien fonctionné. OpenGL est un standard ouvert, donc tant que les fabricants de cartes vidéo sont prêts à produire des pilotes pour XP, il prendra en charge les nouvelles versions d'OpenGL.

D'après ce que je comprends, 3.x a commencé une toute nouvelle façon de faire les choses et j'ai lu dans divers articles et critiques que vous voulez "rester à l'écart des fonctionnalités obsolètes comme glBegin (), glEnd ()" et pourtant beaucoup de livres et des tutoriels que j'ai vus utiliser cette méthode. J'ai vu des gens dire que, fondamentalement, la nouvelle façon de faire les choses est plus compliquée mais que l'ancienne est mauvaise>.>

C'est un très gros problème pour OpenGL. Fondamentalement, dans les temps anciens, vous envoyiez des trucs à la carte vidéo en utilisant le "mode immédiat". Commencez par glBegin, faites des trucs, terminez par glEnd. Cependant, les pilotes de carte vidéo ne le font pas comme ça du tout . Comment peuvent-ils savoir combien de choses vous allez envoyer? Est-ce que ça va être 4 sommets pour un quad texturé ou 100 000 pour un modèle skinné? C'est pourquoi ils ont introduit des objets tampons de vertex (VBO). Alors que le mode immédiat est une liste chaînée, un VBO est un tableau statique. Le développeur sait à quel point c'est gros, le pilote sait à quel point c'est grand. Tout le monde est content. La carte des standards OpenGL (Khronos Group) a donc décidé de déconseiller le mode immédiat pour OpenGL 3.0 et versions ultérieures. Cependant, c'est problématique, comme je vais le montrer avec un exemple simple.

Supposons que vous souhaitiez afficher un quadruple texturé, à partir de zéro.

Dans OpenGL 2.1:

  • Configurez la matrice de projection et insérez-la GL_PROJECTION.
  • Configurez la matrice modelview et insérez-la GL_MODELVIEW.
  • Chargez une image et mettez-la dans une GL_TEXTURE_2Dpoignée.
  • Définissez les positions, les coordonnées de texture et les couleurs de vos sommets.
  • Liez la texture.
  • glBegin... glVertex2f... glTexCoord2f... glEnd.

Dans OpenGL 3.0:

  • Construisez une matrice pour la projection et la vue du modèle.
  • Chargez une image et mettez-la dans une GL_TEXTURE_2Dpoignée.
  • Définissez les positions, les coordonnées de texture et les couleurs de vos sommets et mettez-les dans les VBO.
  • Créez un objet tableau de sommets (VAO) et attachez vos VBO.
  • Écrivez un shader pour sortir un quad texturé et placez-le dans un programme de shader.
  • Attachez les matrices au programme de shader en utilisant des uniformes.
  • Liez la texture.
  • Attachez la texture au programme de shader.
  • glDrawArrays.

Alors, qu'est-ce qui pourrait mal tourner dans la première version?

  • Vos positions sont incorrectes.
  • L'enroulement de votre sommet est dans le mauvais sens.
  • Votre texture ne se charge pas correctement.
  • Votre texture ne se lie pas correctement.
  • Votre matrice de projection est incorrecte.
  • Votre matrice de visualisation de modèle est incorrecte.
  • Vous n'envoyez pas les bons sommets.

Et dans la deuxième version, vous pouvez avoir des problèmes avec ce qui précède et :

  • Vos VBO ont tort.
  • Votre VAO a tort.
  • Votre shader a tort.
  • Votre texture liée au shader est incorrecte.

Sans outils de débogage appropriés, cela devient un problème grave. C'est pourquoi les gens disent que vous devez vous en tenir au mode immédiat. Heureusement, nous avons maintenant le gDEBugger gratuit et excellent , mais ce n'est pas une solution miracle.

Pour répondre à votre question: cela dépend de votre jeu. Si vous souhaitez atteindre un large public (par exemple un jeu occasionnel ou un jeu de plateforme 2D), vous devez cibler 2.1. Si vous créez un jeu spatial épique qui ne fonctionnera pas de toute façon avec du matériel vieux de six ans, ciblez 3.3. Et si vous avez besoin de la dernière et de la plus grande compatibilité future, ciblez 4.0.

chevalier666
la source
2
Je pense que vous montrez un certain parti pris contre VAO / VBO ici. En réalité, si vous vouliez dessiner un quad texturé, vous auriez un ensemble VAO / VBO complet, avec des shaders et des textures déjà créés (au démarrage du programme - personne ne les crée au moment de l'exécution). Dessiner un quad texturé via la nouvelle méthode n'est en réalité qu'une poignée d'appels - il est vrai que cela charge la complexité à l'initialisation du programme tandis que l'ancienne méthode expose la complexité à l'exécution.
Maximus Minimus
2
Mais c'est exactement ce que je voulais dire: maintenant votre bug pourrait être dans vos données (données de sommet et objet de texture), votre programme de shader, votre code de shader, vos matrices, votre téléchargement uniforme ou votre liaison VAO. Si vous partez de rien , c'est beaucoup de sous-systèmes à vérifier! Et vous devez garder une trace de beaucoup plus d'état.
chevalier666
1
Notez que gDEBugger du site gremedy est obsolète. Je suppose abandonné car leurs forums sont fermés depuis longtemps. L'outil a été repris par AMD: gDEBugger .
MichaelHouse
2
"glBegin ... glVertex2f ... glTexCoord2f ... glEnd." Tout simplement pas. glBegin, glVertex etc. n'ont jamais eu raison. glDrawArrays a été introduit dans OpenGL 1.1 (1997) et doit toujours être utilisé sur glBegin et End.
API-Beast
9

Pour quelques statistiques sur la compatibilité matérielle, vous pouvez consulter l'enquête Steam: http://store.steampowered.com/hwsurvey/ Bien qu'elle répertorie DX10 et DX11, la compatibilité matérielle est la même qu'OpenGL 3 et OpenGL 4 respectivement. Notez cependant que l'état d'installation du pilote OpenGL sur les personnes est généralement pire que DX.

Windows XP ne prend pas en charge DX10 ou DX11, mais OpenGL 3 et 4 devrait fonctionner correctement, à condition que les pilotes soient corrects. OSX prend en charge OpenGL 3 (au maximum), sous Linux, vous obtenez OpenGL 4 avec les pilotes du fournisseur ATI / NVIDIA (bien sûr uniquement si le matériel le prend en charge).

Ensuite, il y a aussi les versions mobiles ES d'OpenGL. En fait, je suggère de regarder OpenGL ES 2.0, car il est plus petit, donc plus facile à apprendre, mais vous devez également utiliser des pratiques modernes, à savoir les shaders et les VBO. C'est également ce qui est utilisé sur la plupart des appareils mobiles (vous pouvez donc créer des jeux mobiles) et WebGL est essentiellement le même, vous pouvez donc faire tout votre apprentissage dans le navigateur Web avec ses avantages de développement rapide. OpenGL ES 3.0 est prévu cet été.

La tessellation est une fonctionnalité d'OpenGL 4.0. Vous devriez d'abord apprendre les autres types de shaders, sans parler de toutes les bases, mais je conviens que c'est intéressant - en fait, j'ai écrit un petit test avec: http://blog.tapiov.net/post/15189341463/playing- avec-pavage opengl-4

Tapio
la source
4
Merde, knight666 m'a battu, avec une réponse plus détaillée. Pourtant, la partie ES mérite réflexion.
Tapio