Là, on a un truc qui risque de poser problème dans quelques années. Je m'explique: la création de jeux vidéos et d'applis graphiques commence à reposer de plus en plus sur l'utilisation de "shader programs", écrits par exemple en Cg pour les cartes nvidia (ou directement en assembleur) et compilés avec les outils dédiés pour que ça aille vite (et pas appelés par des fonctions genre glVertexProgramARB).
Le problème est que pour l'instant on ne dispose d'aucun compilateur libre pour faire ces choses, et sans les specs des puces on ira pas bien loin. C'est dommage parce que le libre propose maintenant des moteurs de jeu 3D qui tiennent bien la route (ogre, crystal space...), suffisament AMHA pour concurrencer des moteurs proprios aux licences horriblement chères, mais si au moment de la sortie d'OpenGL 2.0 on a pas rajouté un backend à gcc pour les shaders languages, on va se retrouver le bec dans l'eau et obligé de se rabattre sur des solutions propriétaires. Ca me gênera pas pour mon projet de clône de nethack en python, mais ça risque d'être dommageable pour la pénétration du libre dans le jeu vidéo...
# Re: Cg et la programmation du GPU
Posté par __caffeine__ . En réponse à la dépêche Cg et la programmation du GPU. Évalué à 6.
Le problème est que pour l'instant on ne dispose d'aucun compilateur libre pour faire ces choses, et sans les specs des puces on ira pas bien loin. C'est dommage parce que le libre propose maintenant des moteurs de jeu 3D qui tiennent bien la route (ogre, crystal space...), suffisament AMHA pour concurrencer des moteurs proprios aux licences horriblement chères, mais si au moment de la sortie d'OpenGL 2.0 on a pas rajouté un backend à gcc pour les shaders languages, on va se retrouver le bec dans l'eau et obligé de se rabattre sur des solutions propriétaires. Ca me gênera pas pour mon projet de clône de nethack en python, mais ça risque d'être dommageable pour la pénétration du libre dans le jeu vidéo...