Oui tout à fait. Mon exemple était simpliste à l'extrême pour être le plus explicite possible.
En fait, windu2b, ce que tu proposes est souvent fait entre versions mineures. Dans ce genre de cas, les développeurs vont définir une nouvelle fonction avec une meilleure interface et vont flagguer l'ancienne comme "dépréciée", ce qui (si le langage le permet) va en général générer des warnings à la compilation sans pour autant provoquer de vraie erreur.
Mais parfois c'est plus compliqué. Comme kaouete le dit, il peut y avoir des problèmes de "structures internes". De manière générale, les problèmes compliqués concernent l'architecture globale de l'API qui est trop complexe. Quand on s'en aperçoit après coup, cela implique que le problème n'est pas juste de changer une ou deux fonctions, mais qu'il faudrait changer l'API complète plus en profondeur (plus ou moins). C'est donc compliqué quand le problème vient des choix de "design" originel.
Parfois vous ne pouvez même pas imaginer les choix étranges d'architectures de certaines librairies/programmes! Pour OpenGL en particulier, je ne sais pas, ceci dit.
Ensuite on peut presque toujours faire des fonctions qui appellent d'autres (encapsulation) pour avoir une interface plus agréable. On appelle cela une "abstraction" (on prend quelque chose de concret, par exemple "allumer un pixel à l'écran" pour en faire un concept plus abstrait comme "dessiner un point", donc plus facile à appréhender par l'esprit humain). Mais parfois on veut se limiter pour des raisons de performances. En effet à chaque fois qu'on appelle une fonction, l'ordinateur va la chercher dans la mémoire. Ensuite quand la fonction finit, on doit rechercher la fonction appelante et lui donner la réponse. Tous ces "allers et retours" en mémoire prennent du temps. On appelle cela l'overhead. C'est particulièrement important pour les APIs de bas niveau qu'on veut les plus optimisées possibles (en général on se "relâche" en montant les niveaux, ce qui se voit par le fait que les API bas niveaux sont souvent très concrêtes mais très optimisées alors que le haut niveau est très abstrait avec beaucoup d'overhead).
Donc si on se met à faire massivement ce genre de choses, c'est probablement comme on disait qu'il y a un problème dans l'architecture et que c'est à ce niveau qu'il faudrait revoir l'API.
Enfin pour répondre à Shuba plus haut. C'est vrai que comme OpenGL/DirectX sont fait pour s'interfacer avec du matériel, j'imagine que certaines choses seront limitées si l'API (donc le matériel) ne définit pas certaines fonctionalités.
Ensuite en ce qui concerne les shaders, l'article cite le fait que malgré qu'il n'y avait pas ça dans OpenGL à une époque, cela avait ajouté par extension avant que ce soit dans l'API. En outre, ça ne semble pas gêner Carmack plus que cela, et il ne parle pas de différence de performance. Donc cet exemple me semblait pertinent.
Ensuite comme je disais, je ne connais pas le sujet de la 3D en particulier. Et tu as sans doute raison.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 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é à 4.
Oui tout à fait. Mon exemple était simpliste à l'extrême pour être le plus explicite possible.
En fait, windu2b, ce que tu proposes est souvent fait entre versions mineures. Dans ce genre de cas, les développeurs vont définir une nouvelle fonction avec une meilleure interface et vont flagguer l'ancienne comme "dépréciée", ce qui (si le langage le permet) va en général générer des warnings à la compilation sans pour autant provoquer de vraie erreur.
Mais parfois c'est plus compliqué. Comme kaouete le dit, il peut y avoir des problèmes de "structures internes". De manière générale, les problèmes compliqués concernent l'architecture globale de l'API qui est trop complexe. Quand on s'en aperçoit après coup, cela implique que le problème n'est pas juste de changer une ou deux fonctions, mais qu'il faudrait changer l'API complète plus en profondeur (plus ou moins). C'est donc compliqué quand le problème vient des choix de "design" originel. Parfois vous ne pouvez même pas imaginer les choix étranges d'architectures de certaines librairies/programmes! Pour OpenGL en particulier, je ne sais pas, ceci dit.
Ensuite on peut presque toujours faire des fonctions qui appellent d'autres (encapsulation) pour avoir une interface plus agréable. On appelle cela une "abstraction" (on prend quelque chose de concret, par exemple "allumer un pixel à l'écran" pour en faire un concept plus abstrait comme "dessiner un point", donc plus facile à appréhender par l'esprit humain). Mais parfois on veut se limiter pour des raisons de performances. En effet à chaque fois qu'on appelle une fonction, l'ordinateur va la chercher dans la mémoire. Ensuite quand la fonction finit, on doit rechercher la fonction appelante et lui donner la réponse. Tous ces "allers et retours" en mémoire prennent du temps. On appelle cela l'overhead. C'est particulièrement important pour les APIs de bas niveau qu'on veut les plus optimisées possibles (en général on se "relâche" en montant les niveaux, ce qui se voit par le fait que les API bas niveaux sont souvent très concrêtes mais très optimisées alors que le haut niveau est très abstrait avec beaucoup d'overhead). Donc si on se met à faire massivement ce genre de choses, c'est probablement comme on disait qu'il y a un problème dans l'architecture et que c'est à ce niveau qu'il faudrait revoir l'API.
Enfin pour répondre à Shuba plus haut. C'est vrai que comme OpenGL/DirectX sont fait pour s'interfacer avec du matériel, j'imagine que certaines choses seront limitées si l'API (donc le matériel) ne définit pas certaines fonctionalités. Ensuite en ce qui concerne les shaders, l'article cite le fait que malgré qu'il n'y avait pas ça dans OpenGL à une époque, cela avait ajouté par extension avant que ce soit dans l'API. En outre, ça ne semble pas gêner Carmack plus que cela, et il ne parle pas de différence de performance. Donc cet exemple me semblait pertinent. Ensuite comme je disais, je ne connais pas le sujet de la 3D en particulier. Et tu as sans doute raison.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]