j'ai bien compris la différence DirectX/OpenGL, [...] mais une plate-forme multimédia unifiée (justement façon DirectX), ça me plairait bien.
Donc non, tu n'as pas bien compris la différence entre DirectX et OpenGL. Le dernier, justement, sert à faire du rendu 2D/3D et ne sert qu'à ça. En fait, je crois que c'est plus la distinction entre les philosophies de base de windows et d'unix, que tu n'as pas comprise : dans un cas on intègre tout au maximum, sans doute pour montrer qu'on a « la plus grosse boîte » ou bien parce que comme ça, l'utilisateur « ne perd pas de temps » ; dans l'autre, on n'hésite pas à fragmenter pour assurer une fonctionnalité ciblée et un choix accru (pour les autres services, ici son/réseau/entrées...)
Et pis grosse question, comme Carmack fait-il pour gérer ttes ces apis !
Toute petite réponse : Carmack codait déjà quand j'étais tout petit (allez, « presque »).
Enfin (et là je vais donner l'impression de me renier à ceux qui me connaissent ;), c++ c'est bien, oui, mais on n'a certainement pas besoin d'en avoir partout. Les fonctions d'opengl réalisent des tâches tellement primitives qu'il serait inapproprié de les encombrer d'une approche objet.
[La suite est un peu longue et technique.]
Par exemple, la programmation type « machine à état » est beaucoup plus appropriée que l'utilisation de classes avec constructeurs/destructeurs, le tout étant prévu pour fonctionner avec peu ou pas d'invariants vérifiés par le système.
A côté de ça, le polymorphisme ad hoc (fonctions virtuelles et rtti, en c++ ; tout ce qui est polymorphisme dynamique) n'a évidemment pas sa place dans le type d'applications visées... si tant est qu'on puisse déjà bâtir des hiérarchies avec les classes d'un système de si bas niveau !
Question polymorphisme statique... aucun rapport. On passe.
Les exceptions : ce serait élégant mais, comme dit plus haut, on en aurait pas besoin souvent. En fait, ça ne servirait qu'à empêcher les liaisons avec la plupart des autres langages, notamment C.
Non, franchement, les deux seuls éléments du c++ qui pourraient bénéficier à opengl :
- les namespaces, sauf que les dév de libs C ont, depuis toujours, une réponse équivalente : le préfixage des noms de fonctions et l'utilisation intensive du niveau de linkage interne (static au niveau global) ;
- la surcharge de fonctions, et encore... les ambiguïtés pleuveraient tellement que ça ne serait pas la peine ; avec le système de suffixes, on sait tout de suite ce qui se passe sans avoir à y réfléchir (et c'est pourtant un des buts de c++, de « désobfusquer » le code).
Donc non, franchement, je ne vois pas pourquoi on pourrait vouloir d'un opengl en c++ (extern "C" étant ton ami, et il est déjà dans tous les headers). Je suis même à peu près convaincu que ce genre de regret dénote un manque de compréhension de la portée ou de l'intention d'opengl.
... Et je me fais cette réflexion en relisant mon commentaire : en fait, tu ne regrettes pas fondamentalement qu'opengl ne soit pas « écrit en c++ ». Juste qu'en ayant l'air de dire cela, tu dis plutôt que n'as pas trouvé l'ensemble de ce que tu cherches. Un petit conseil : regarde SDL d'un peu plus près, pour ce qui est de l'intégration des services. Pour ce qui est du haut niveau (qui justifierait l'OO et tout), tu le dis toi-même : « je préfererais le développer moi-même ».
[^] # Re: paradigmes divergents !
Posté par gourgou . En réponse au journal Développer des jeux vidéos sous Linux ?. Évalué à 8.
Donc non, tu n'as pas bien compris la différence entre DirectX et OpenGL. Le dernier, justement, sert à faire du rendu 2D/3D et ne sert qu'à ça. En fait, je crois que c'est plus la distinction entre les philosophies de base de windows et d'unix, que tu n'as pas comprise : dans un cas on intègre tout au maximum, sans doute pour montrer qu'on a « la plus grosse boîte » ou bien parce que comme ça, l'utilisateur « ne perd pas de temps » ; dans l'autre, on n'hésite pas à fragmenter pour assurer une fonctionnalité ciblée et un choix accru (pour les autres services, ici son/réseau/entrées...)
Et pis grosse question, comme Carmack fait-il pour gérer ttes ces apis !
Toute petite réponse : Carmack codait déjà quand j'étais tout petit (allez, « presque »).
Enfin (et là je vais donner l'impression de me renier à ceux qui me connaissent ;), c++ c'est bien, oui, mais on n'a certainement pas besoin d'en avoir partout. Les fonctions d'opengl réalisent des tâches tellement primitives qu'il serait inapproprié de les encombrer d'une approche objet.
[La suite est un peu longue et technique.]
Par exemple, la programmation type « machine à état » est beaucoup plus appropriée que l'utilisation de classes avec constructeurs/destructeurs, le tout étant prévu pour fonctionner avec peu ou pas d'invariants vérifiés par le système.
A côté de ça, le polymorphisme ad hoc (fonctions virtuelles et rtti, en c++ ; tout ce qui est polymorphisme dynamique) n'a évidemment pas sa place dans le type d'applications visées... si tant est qu'on puisse déjà bâtir des hiérarchies avec les classes d'un système de si bas niveau !
Question polymorphisme statique... aucun rapport. On passe.
Les exceptions : ce serait élégant mais, comme dit plus haut, on en aurait pas besoin souvent. En fait, ça ne servirait qu'à empêcher les liaisons avec la plupart des autres langages, notamment C.
Non, franchement, les deux seuls éléments du c++ qui pourraient bénéficier à opengl :
- les namespaces, sauf que les dév de libs C ont, depuis toujours, une réponse équivalente : le préfixage des noms de fonctions et l'utilisation intensive du niveau de linkage interne (static au niveau global) ;
- la surcharge de fonctions, et encore... les ambiguïtés pleuveraient tellement que ça ne serait pas la peine ; avec le système de suffixes, on sait tout de suite ce qui se passe sans avoir à y réfléchir (et c'est pourtant un des buts de c++, de « désobfusquer » le code).
Donc non, franchement, je ne vois pas pourquoi on pourrait vouloir d'un opengl en c++ (extern "C" étant ton ami, et il est déjà dans tous les headers). Je suis même à peu près convaincu que ce genre de regret dénote un manque de compréhension de la portée ou de l'intention d'opengl.
... Et je me fais cette réflexion en relisant mon commentaire : en fait, tu ne regrettes pas fondamentalement qu'opengl ne soit pas « écrit en c++ ». Juste qu'en ayant l'air de dire cela, tu dis plutôt que n'as pas trouvé l'ensemble de ce que tu cherches. Un petit conseil : regarde SDL d'un peu plus près, pour ce qui est de l'intégration des services. Pour ce qui est du haut niveau (qui justifierait l'OO et tout), tu le dis toi-même : « je préfererais le développer moi-même ».