Journal : Développer des jeux vidéos sous Linux ?
Posté par Martyanoff Nicolas (Jabber id, page perso, ) le 17 avril 2005
Bonjour,
Me posant de nombreuses questions concernant la programmation de jeux vidéos sous linux, je me suis décidé à rédiger un petit journal sur DLFP. A l'origine, je codais sous Windows. Fana de jeux vidéos, je me suis vite tourné vers leurs programmation, découvrant avec étonnement et motivation un monde absolument énorme. J'ai vite abordé DirectX, et j'ai été enthousiasmé par les possibilités offertes par cette API.
Mais quand je suis passé sous Linux, il m'a fallut me tourner vers autre chose. Après pas mal de recherches, de tatonnements avec glut, DevIL, et autre joyeusetés, j'ai découvert SDL (doooh, c'est chouette, c'est simple, et ça fait plein de choses), et OpenGL. Pour ce dernier, c'est autre chose. Je découvre avec déception une API certe stable et plutôt simple d'accès, mais... en C ! Quoi, pas de prog OO pour une API servant à coder des jeux vidéos ?
Et puis zut alors, c'est quoi cette histoire d'extensions ATI/NV/ARB ?
Bon, d'après les screens que j'ai vu sur le net, on peut faire des choses trèèèèès jolies en OpenGL, mais quand même, du C... Je sais, le C c'est très bien, on a codé le kernel avec, mais bon, quand même...
Actuellement, ma grosse motivation est que si Carmack a pu coder Doom 3 en OpenGL, c'est que ça doit marcher plutôt bien, mais alors Doom 3 est en C ? Ou alors tout est encapsulé. Et puis il utilise quoi, le monsieur, pour gérer les inputs, les sons, les vidéos, le réseau ? Pas SDL que je sache.
Il y a 3 mois, je me battais pour trouver une IDE C++ graphique sous nux, et puis finalement je me suis rendu compte que je préférais vim (pas de troll merci) + console, mais j'avoue que l'absence d'interface C++ à OpenGL me dégoûte un petit peu, sinon beaucoup. Peut être que d'ici 3 mois, j'apprécierai d'avoir recours a tout plein d'extension pour gérer chaque effet. Peut être que dans 3 mois, j'apprécierai de devoir installer, configurer, et maîtriser tout pleins d'APIs pour coder un jeu.
Je veux devenir développeur de jeux vidéos, et comme j'aime Linux, je
veux développer sous Linux, mais est-ce vraiment possible, de A à Z ?
Autant d'interrogations que je ne dois pas être le seul à avoir, qui me turlupinent, parce que j'aimerais bien coder du jeux vidéo sous Nux, moi et autre chose que la 2d permise par SDL (par contre je suis objectif, la 2d sous SDL ça marche au top).
Alors, je rêve ? Je fantasme ?
Pitié, montrez-moi qu'il y a de l'espoir.
Me posant de nombreuses questions concernant la programmation de jeux vidéos sous linux, je me suis décidé à rédiger un petit journal sur DLFP. A l'origine, je codais sous Windows. Fana de jeux vidéos, je me suis vite tourné vers leurs programmation, découvrant avec étonnement et motivation un monde absolument énorme. J'ai vite abordé DirectX, et j'ai été enthousiasmé par les possibilités offertes par cette API.
Mais quand je suis passé sous Linux, il m'a fallut me tourner vers autre chose. Après pas mal de recherches, de tatonnements avec glut, DevIL, et autre joyeusetés, j'ai découvert SDL (doooh, c'est chouette, c'est simple, et ça fait plein de choses), et OpenGL. Pour ce dernier, c'est autre chose. Je découvre avec déception une API certe stable et plutôt simple d'accès, mais... en C ! Quoi, pas de prog OO pour une API servant à coder des jeux vidéos ?
Et puis zut alors, c'est quoi cette histoire d'extensions ATI/NV/ARB ?
Bon, d'après les screens que j'ai vu sur le net, on peut faire des choses trèèèèès jolies en OpenGL, mais quand même, du C... Je sais, le C c'est très bien, on a codé le kernel avec, mais bon, quand même...
Actuellement, ma grosse motivation est que si Carmack a pu coder Doom 3 en OpenGL, c'est que ça doit marcher plutôt bien, mais alors Doom 3 est en C ? Ou alors tout est encapsulé. Et puis il utilise quoi, le monsieur, pour gérer les inputs, les sons, les vidéos, le réseau ? Pas SDL que je sache.
Il y a 3 mois, je me battais pour trouver une IDE C++ graphique sous nux, et puis finalement je me suis rendu compte que je préférais vim (pas de troll merci) + console, mais j'avoue que l'absence d'interface C++ à OpenGL me dégoûte un petit peu, sinon beaucoup. Peut être que d'ici 3 mois, j'apprécierai d'avoir recours a tout plein d'extension pour gérer chaque effet. Peut être que dans 3 mois, j'apprécierai de devoir installer, configurer, et maîtriser tout pleins d'APIs pour coder un jeu.
Je veux devenir développeur de jeux vidéos, et comme j'aime Linux, je
veux développer sous Linux, mais est-ce vraiment possible, de A à Z ?
Autant d'interrogations que je ne dois pas être le seul à avoir, qui me turlupinent, parce que j'aimerais bien coder du jeux vidéo sous Nux, moi et autre chose que la 2d permise par SDL (par contre je suis objectif, la 2d sous SDL ça marche au top).
Alors, je rêve ? Je fantasme ?
Pitié, montrez-moi qu'il y a de l'espoir.
> Lire le journal (32 commentaires, moyenne: 2,7).
Vous avez demandé le commentaire #562419.
Run by 
Cette page a été générée par Templeet en 0.0398s (dont 0.0037 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Moteur 3D
Ce que tu rechercherais, ce ne serait pas plutôt un moteur 3D (ce que n'est pas SDL) ? Tu as du te rendre compte qu'OpenGL est une API très bas niveau pour gérer des rudiments d'une scène 3D. Pour ce qui est de la gestion des phénomènes physiques (gravité, chocs, friction, etc...), ombres portées, mouvement par contraintes, import d'objets issus des modeleurs, etc... bah tu dois tout faire toi même.
Même avec un binding C++, je ne pense pas qu'OpenGL sera beaucoup plus pratique à utiliser. Ce n'est pas le but, le but étant que ça soit facilement gérable au niveau matériel.
Bref, ce qu'il te faudrait c'est une API d'un peu plus haut niveau encapsulant les appels à OpenGL. J'en connais deux, et utilisé seulement un :
- Soya 3D : utilisé par Slune, écrit en Python. C'est celui que j'ai utilisé pour mes très maigres besoins. Il est vraiment très facile à utiliser.
- Blender : Là aussi, c'est du python. Mais je ne me suis pas trop penché sur cet outil.
Il doit y en avoir d'autres avec des bindings C++, comme tu sembles y être attaché. Le point clé de ce message étant qu'OpenGL ne t'offrira jamais de fonctions de haut niveau, donc cherche ailleurs.