Pour compléter ce qui a été dit dans les autres posts, il faut quand même garder à l'esprit qu'OpenGL n'a pas grand chose à voir avec Direct3D. En effet, ce dernier existe principalement pour le jeu. En revanche, OpenGL est présent sur la totalité des stations de travail (IBM, Sun, SGI & consort) et les applications de simulation ou de visualisation reposent fortement dessus. Donc à mon avis, la mort d'OpenGL n'est pas pour demain.
Pour ce qui est de l'évolution, tout dépend aussi de l'architecture des ordinateurs. Du peu que je connais des stations que j'ai cotoyées lors de mes études, j'aurais plutôt tendance à dire que l'on a régressé avec les cartes graphiques embarquant leur propre mémoire. On a certes gagné en rapidité mais on a aussi beaucoup perdu en fonctionnalité. En effet, sur les machines à mémoire unifiée, les vertex arrays et les textures étaient d'une grande puissance : le programme modifiait les buffers et les modifications se répercutaient immédiatement à l'écran. Pour retrouver cette puissance, les constructeurs (puis l'ARB) ont dû sortir les render to texture ou les VBO pour rerattraper le retard (tout comme avec la récente GLX_EXT_texture_from_pixmap utilisée par Xgl). Et nous en sommes encore loin puisqu'il y a toujours besoin de faire des transferts entre mémoire centrale et mémoire graphique. Tout ça pour dire que la seule grande innovation depuis belles lurettes est les shaders.
Pour poursuivre sur les shaders, Direct3D a suivit le matériel (enfin ... celui accessible aux utilisateurs de PCs), on a donc eu plusieurs versions et révisions pour les shaders. Mystérieusement pour OpenGL, on a 1 seule version (avec quand même des révisions mineures). Mes drivers Nvidia me disent "vous avez les shaders de disponible !", je dis "youpi \o/" et pourtant ma gffx5200 supporte partiellement les buffers en flottant et les instructions de saut en sont absentes. Il a fallu donc qu'ATI, Nvidia & les autres arrivent à implémenter les spec d'OpenGL/GLSL dans leurs GPU et cela leur a pris du temps (3 générations de GPU pour Nvidia). Pendant ce temps là, OpenGL stagnait car personne ne l'implémentait à 100% en hard ou n'avait pas besoin de plus.
OpenGL est certes vieux mais on ne change pas une API éprouvée du jour au lendemain. D'ailleurs 3DLabs s'était pris une belle claque en 2001/2002 car ils avaient réfléchi sur un OpenGL 2.0 où il le remettait entièrement à plat. Mais bon, les specs ont disparu du web et rien ne semblent présager leur retour sur le devant de la scène ; c'est triste ...
Dans ton énumération des API reprenant l'approche d'OpenGL pour des domaines plus spécifiques, tu oublies OpenAL pour le son (et qui pourra sûrement t'intéresser quand tu t'attaqueras au son dans ton jeu:)
À propos de ton jeu, quelle méthode utilises tu pour le terrain ? heighmap avec un quadtree ? octree ? ROAM ? CLOD ? j'avoue avoir laché un "merde ! y dit pas quel algo il utilise" O:-)
mes 2¢ ... allez ! 3¢ vu le nombre de caractères :]
# OpenGL n'avance peut être pas mais qu'en est-il des ordinateurs ?
Posté par Rémi Hérilier . En réponse au journal Où en est-t-on avec OpenGL ?. Évalué à 10.
Pour ce qui est de l'évolution, tout dépend aussi de l'architecture des ordinateurs. Du peu que je connais des stations que j'ai cotoyées lors de mes études, j'aurais plutôt tendance à dire que l'on a régressé avec les cartes graphiques embarquant leur propre mémoire. On a certes gagné en rapidité mais on a aussi beaucoup perdu en fonctionnalité. En effet, sur les machines à mémoire unifiée, les vertex arrays et les textures étaient d'une grande puissance : le programme modifiait les buffers et les modifications se répercutaient immédiatement à l'écran. Pour retrouver cette puissance, les constructeurs (puis l'ARB) ont dû sortir les render to texture ou les VBO pour rerattraper le retard (tout comme avec la récente GLX_EXT_texture_from_pixmap utilisée par Xgl). Et nous en sommes encore loin puisqu'il y a toujours besoin de faire des transferts entre mémoire centrale et mémoire graphique. Tout ça pour dire que la seule grande innovation depuis belles lurettes est les shaders.
Pour poursuivre sur les shaders, Direct3D a suivit le matériel (enfin ... celui accessible aux utilisateurs de PCs), on a donc eu plusieurs versions et révisions pour les shaders. Mystérieusement pour OpenGL, on a 1 seule version (avec quand même des révisions mineures). Mes drivers Nvidia me disent "vous avez les shaders de disponible !", je dis "youpi \o/" et pourtant ma gffx5200 supporte partiellement les buffers en flottant et les instructions de saut en sont absentes. Il a fallu donc qu'ATI, Nvidia & les autres arrivent à implémenter les spec d'OpenGL/GLSL dans leurs GPU et cela leur a pris du temps (3 générations de GPU pour Nvidia). Pendant ce temps là, OpenGL stagnait car personne ne l'implémentait à 100% en hard ou n'avait pas besoin de plus.
OpenGL est certes vieux mais on ne change pas une API éprouvée du jour au lendemain. D'ailleurs 3DLabs s'était pris une belle claque en 2001/2002 car ils avaient réfléchi sur un OpenGL 2.0 où il le remettait entièrement à plat. Mais bon, les specs ont disparu du web et rien ne semblent présager leur retour sur le devant de la scène ; c'est triste ...
Dans ton énumération des API reprenant l'approche d'OpenGL pour des domaines plus spécifiques, tu oublies OpenAL pour le son (et qui pourra sûrement t'intéresser quand tu t'attaqueras au son dans ton jeu:)
À propos de ton jeu, quelle méthode utilises tu pour le terrain ? heighmap avec un quadtree ? octree ? ROAM ? CLOD ? j'avoue avoir laché un "merde ! y dit pas quel algo il utilise" O:-)
mes 2¢ ... allez ! 3¢ vu le nombre de caractères :]