je ne fais pas de 3D, mais je suis développeur. Et donc de ce que je comprends des termes employés, notez tout de même que Carmack ne semble pas critiquer la qualité finale d'OpenGL, mais son API seulement, ce qui pour nous programmeurs peut être synonyme de "simplicité d'utilisation". Pour exprimer cela simplement, voici une analyse du discours:
I actually think that Direct3D is a rather better API today.
imaginez que pour dessiner un cube de côté l, une bonne API a une fonction cube(l) alors qu'une moins bonne aurait la fonction make_a_regular_hexahedron(d) où d est la diagonale et non le côté. C'est chiant à développer car le nom de la fonction est plus long et mal choisi (un regular hexahedron est un cube, le nom n'est pas clair). Aussi bien que l'on sache sache calculer sans problème le côté en fonction de la diagonale et vis-versa, "en général" les gens vont vouloir dessiner un cube dont il connaisse le côté, non la diagonale. Donc la seconde fonction demandera la plupart du temps une ligne de calcul supplémentaire dans le code: paramètre mal choisi.
C'est cela que l'on appelle une mauvaise API (Interface!) en général.
Microsoft had the courage to continue making significant incompatible changes to improve the API, while OpenGL has been held back by compatibility concerns
De même quand il parle de compatibilité, il entend donc une pratique courante. Plus tard, on se rend compte que notre fonction make_a_regular_hexahedron est vraiment chiante à utiliser. On aimerait bien changer le nom et le type de paramètre. Mais voilà, plein de logiciels l'utilisent et si on change cela, ça va "casser" la compatibilité ascendante => les développeurs devront revoir leur code et changer tous les endroits où ils créaient un cube avant s'ils veulent utiliser la nouvelle API.
C'est quelque chose que les bonnes APIs refusent de faire de manière générale sauf en passant une version majeure où ils se permettent de casser plein de choses. C'est un choix accepté, en particulier dans le logiciel Libre où ce serait très dur de suivre les évolutions de toutes les librairies et on essaie de se fier aux numéros de version.
Direct3D handles multi-threading better, and newer versions manage state better.
Cela confirme assez. Il dit bien que c'est mieux géré (donc plus simple à utiliser ou mettre en œuvre), pas que c'est plus efficace.
Maintenant quand il parle de nouvelles fonctionnalités, cela implique surtout que l'API Direct3D a intégré des facilités dans son interface. Supposons qu'aucune des API ne savait faire des boules. Puis notre bonne API se dit: tiens, je vais intégrer un algorithme pour faire une boule et j'encapsule ça dans une fonction que j'appelerai ball(r). On peut maintenant faire des boules en une ligne de code.
De son côté la mauvaise API n'a pas la fonction encore. Cela ne signifie pas que les développeurs ne peuvent pas faire de boule. Simplement ils sont obligés de calculer eux même ses limites, puis les remplir (avec d'autres types d'objets que l'API sait faire). C'est donc chiant.
C'est en gros, ce qu'ils disent dans l'article là:
While newer versions of OpenGL have kept up-to-date with some of the features found in DirectX, including DirectX 10's geometry shader, they usually have to be implemented via extensions, rather than the main API.
Enfin tout cela est confirmé par:
we wouldn’t get any huge benefits by making the switch, so I can’t work up much enthusiasm for cleaning it out of our codebase.
où Carmack explique que maintenant ils utilisent OpenGL et que s'ils passaient à DirectX ça ferait beaucoup de boulot (même si ce dernier est visiblement plus facile à utiliser, leur base de code depuis les années doit être énorme), pour au final peu de bénéfice. Les bénéfices évidents avec une meilleure API: plus facile à maintenir (débugguer, etc.). Mais comme ils ont déjà une base très solide, ils n'y touchent sûrement plus autant qu'avant. Donc ce bénéfice est au final minime comparé au travail colossal de tout changer pour Direct3D. Quant à l'utilisateur final, il n'y verra probablement aucune différence car les deux APIs sont aussi performantes ou proches à mon avis. En effet si cela impliquait vraiment une différence pour l'utilisateur (plus fluide et/ou plus beau), alors ce serait vraiment un énorme bénéfice, surtout pour le domaine du shoot 3d, fer de lance de cette entreprise où le graphisme règne en maître. Si ça ne l'est pas, c'est que la seule différence est probablement pour le développement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Meilleure interface de développement, pas forcément meilleure 3D
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Direct3D vs OpenGL. Évalué à 9.
Bonjour,
je ne fais pas de 3D, mais je suis développeur. Et donc de ce que je comprends des termes employés, notez tout de même que Carmack ne semble pas critiquer la qualité finale d'OpenGL, mais son API seulement, ce qui pour nous programmeurs peut être synonyme de "simplicité d'utilisation". Pour exprimer cela simplement, voici une analyse du discours:
imaginez que pour dessiner un cube de côté l, une bonne API a une fonction
cube(l)alors qu'une moins bonne aurait la fonctionmake_a_regular_hexahedron(d)où d est la diagonale et non le côté. C'est chiant à développer car le nom de la fonction est plus long et mal choisi (un regular hexahedron est un cube, le nom n'est pas clair). Aussi bien que l'on sache sache calculer sans problème le côté en fonction de la diagonale et vis-versa, "en général" les gens vont vouloir dessiner un cube dont il connaisse le côté, non la diagonale. Donc la seconde fonction demandera la plupart du temps une ligne de calcul supplémentaire dans le code: paramètre mal choisi.C'est cela que l'on appelle une mauvaise API (Interface!) en général.
De même quand il parle de compatibilité, il entend donc une pratique courante. Plus tard, on se rend compte que notre fonction
make_a_regular_hexahedronest vraiment chiante à utiliser. On aimerait bien changer le nom et le type de paramètre. Mais voilà, plein de logiciels l'utilisent et si on change cela, ça va "casser" la compatibilité ascendante => les développeurs devront revoir leur code et changer tous les endroits où ils créaient un cube avant s'ils veulent utiliser la nouvelle API.C'est quelque chose que les bonnes APIs refusent de faire de manière générale sauf en passant une version majeure où ils se permettent de casser plein de choses. C'est un choix accepté, en particulier dans le logiciel Libre où ce serait très dur de suivre les évolutions de toutes les librairies et on essaie de se fier aux numéros de version.
Cela confirme assez. Il dit bien que c'est mieux géré (donc plus simple à utiliser ou mettre en œuvre), pas que c'est plus efficace.
Maintenant quand il parle de nouvelles fonctionnalités, cela implique surtout que l'API Direct3D a intégré des facilités dans son interface. Supposons qu'aucune des API ne savait faire des boules. Puis notre bonne API se dit: tiens, je vais intégrer un algorithme pour faire une boule et j'encapsule ça dans une fonction que j'appelerai
ball(r). On peut maintenant faire des boules en une ligne de code. De son côté la mauvaise API n'a pas la fonction encore. Cela ne signifie pas que les développeurs ne peuvent pas faire de boule. Simplement ils sont obligés de calculer eux même ses limites, puis les remplir (avec d'autres types d'objets que l'API sait faire). C'est donc chiant. C'est en gros, ce qu'ils disent dans l'article là:Enfin tout cela est confirmé par:
où Carmack explique que maintenant ils utilisent OpenGL et que s'ils passaient à DirectX ça ferait beaucoup de boulot (même si ce dernier est visiblement plus facile à utiliser, leur base de code depuis les années doit être énorme), pour au final peu de bénéfice. Les bénéfices évidents avec une meilleure API: plus facile à maintenir (débugguer, etc.). Mais comme ils ont déjà une base très solide, ils n'y touchent sûrement plus autant qu'avant. Donc ce bénéfice est au final minime comparé au travail colossal de tout changer pour Direct3D. Quant à l'utilisateur final, il n'y verra probablement aucune différence car les deux APIs sont aussi performantes ou proches à mon avis. En effet si cela impliquait vraiment une différence pour l'utilisateur (plus fluide et/ou plus beau), alors ce serait vraiment un énorme bénéfice, surtout pour le domaine du shoot 3d, fer de lance de cette entreprise où le graphisme règne en maître. Si ça ne l'est pas, c'est que la seule différence est probablement pour le développement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]