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.
Journal Développer des jeux vidéos sous Linux ?
17
avr.
2005
# Réutiliser le code
Posté par un_brice (site web personnel) . Évalué à 10.
Plutôt que de redévelopper un n-ième moteur, reprends ceux qui sont libres et qui existent !
On parle beaucoup de Ogre par exemple (cf http://www.ogre3d.org/(...) et http://www.ogre3d.org/wiki/index.php/Projects_using_OGRE(...) ). Ça a l'air d'être du C++ (je suppose que tu aime ça...), c'est sous LGPL et ça se veut généraliste.
Et si il te plait pas y'en a pleins, comme Nevrax ( http://nevrax.org(...) ) par exemple.
Sinon, je ne comprends pas bien ce que tu reproche au C, mais je préfère qu'on en parle pas, sinon c'est troll rasoir assuré -_^
# quake2 ?
Posté par Marc (site web personnel) . Évalué à 3.
# SDL, C++ et la 3D
Posté par foulmetal canette (site web personnel) . Évalué à 5.
http://www.libsdl.org/opengl/index.php(...)
Bon un exemple de jeu libre, au hasard, écrit en SDL/OpenGL C++ :
http://happypenguin.org/show?GL-117(...)
[^] # Re: SDL, C++ et la 3D
Posté par foulmetal canette (site web personnel) . Évalué à 6.
https://savannah.nongnu.org/projects/crack-attack(...)
http://aluminumangel.org/attack/(...)
# En haut niveau il y a le python...
Posté par Snark_Boojum . Évalué à 3.
Snark
[^] # Re: En haut niveau il y a le python...
Posté par Adrien Bourdet . Évalué à 1.
Sur le site de balazar, il y a des tutos pour découvrir la programmation de soya. On se rend compte que c'est assez simple a faire, pour un résultat très satisfaisant. (merci Jiba)
PS : pour ceux qui ne sont pas au courant, python "est" orienté objet.
# Moteur 3D
Posté par pierthi . Évalué à 4.
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.
# OpenGL, SGI, l'histoire de la 3D, toussa...
Posté par Guillaume Knispel . Évalué à 7.
A vrai dire j'ai meme l'impression que tu connaissais meme pas OpenGL de nom avant d'apprendre DirectX et ca me fait encore plus peur en pensant au pouvoir de microsoft...
OpenGL c'est un truc inventé par SGI bien avant que DirectX ne naisse, dont l'API est normalisée, et dont des implémentations existent sous un bon nombre d'Unix et pas seulement Linux mais aussi sous Win. Si bindings C++ il y a, ils ne seront eux pas normalisés.
Une derniere chose : ce n'est pas parce que tu as une API en C que tu es obligé de l'utiliser avec un programme en C. Le C++ a justement été créé avec en tête la compatibilité des deux langages au niveau source et dans une moindre mais tout de même large mesure binaire.
Enfin, rien n'empeche de faire de l'OO en C (la plupart des programmes bien écrit en C le sont d'ailleur ainsi).
[^] # Re: OpenGL, SGI, l'histoire de la 3D, toussa...
Posté par Anonyme . Évalué à 1.
Et je ne cherche pas un moteur, car ça, je préfererais le développer moi-même, mais une plate-forme multimédia unifiée (justement façon DirectX), ça me plairait bien.
Exemple, les shaders. Sous DirectX, ça fait partie du système, c'est parfaitement intégré.
Sous OpenGL, il faut aller chercher des extensions selons la cg que l'on a, c'est tout sauf pratique.
Pour les inputs ? Une autre lib.
Pour les médias ? Une autre lib.
Pour l'audio ? Une autre lib.
Pour le réseau ? Une autre lib.
Oui, OpenGL n'est pas DirectX, mais disons de manière mieux formulée que j'aurais voulu qu'il existe un système façon dx sous linux.
Et pis grosse question, comme Carmack fait-il pour gérer ttes ces apis ! (et puis en général les codeurs de NeverwinterNights, UT2004, etc...)
[^] # Re: OpenGL, SGI, l'histoire de la 3D, toussa...
Posté par fredix . Évalué à 4.
Pour les inputs ? Une autre lib.
Pour les médias ? Une autre lib.
Pour l'audio ? Une autre lib.
Pour le réseau ? Une autre lib.
La libSDL fait tout cela ....
[^] # Re: OpenGL, SGI, l'histoire de la 3D, toussa...
Posté par elloco (site web personnel) . Évalué à 3.
[^] # Re: OpenGL, SGI, l'histoire de la 3D, toussa...
Posté par jojolapin4 . Évalué à 2.
D'un point de vue personnel d'ailleurs, j'ai pris bien plus de plaisirs en utilisant SDL/Clanlib/OpenGl/etc. que DirectX, que je trouve plus compliqué à manier (encore que je n'ai pas testé le Managed DirectX, qui est parait-il bien plus agréable que le DirectX non managé).
[^] # Re: OpenGL, SGI, l'histoire de la 3D, toussa...
Posté par Meku (site web personnel) . Évalué à 4.
Non, plus maintenant avec GLSL (OpenGL Shading Language) ! Pour le moment on y accède via une extension ARB, mais ce sera bientôt totalement intégré dans l'API OpenGL.
Mais plus besoin de faire au cas par cas pour les cartes graphiques, sauf peut-être pour les plus vieilles dont on peu en tirer mieux avec les extensions propriétaires (NV, ATI) qu'avec une implémentation « faible » de GLSL pour elles.
Pour ce qui est d'une interface en C++, bon..., ça dépend des gouts hein... Franchement l'API DirectX, ce que j'en pense de son style... :-)
[^] # Re: paradigmes divergents !
Posté par gourgou . É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 ».
[^] # Re: paradigmes divergents !
Posté par Anonyme . Évalué à -2.
Pour faire simple, je sais que je suis plutôt difficile.
- La SDL, peut être utilisée de deux manières:
* Seule, en tant qu'API multimédia, auquel cas elle fait du très bon travail en 2D.
* En conjonction avec OpenGL auquel cas elle sert plus de panel de fonctions à la façon de GLUT. Ok, elle gère quand même 'un poil' plus de choses que GLUT, mais c'est un peu le principe, non ?
Jusque là, je l'utilisais de la première manière, et j'hesite à passer à la seconde, me demandant de que les pros utilisent.
- Le troll C vs C++ n'est pas nouveau, mais à mon goût, le C++ est beaucoup plus flexible, sûr et intuitif que le C. Effectivement, c'est un poil plus lourd, et parfois 'overkill', mais dire froidement que dans le cas de l'OpenGL, ça ne servirait à rien... Personnellement, avoir de la surcharge d'opérateurs, des exceptions, et du polymorphisme (ne serait-ce que ça), je ne dirais pas non.
- Pour les APIs python, pas la peine, je ne code pas en python, et ne l'envisage pas, je souhaite coder en C++ :)
- Là je viens de télécharger la source de quake2, ça m'a l'air plutôt bien foutu, donc je vais étudier tout ça.
[^] # Re: paradigmes divergents !
Posté par gourgou . Évalué à 3.
* Seule, en tant qu'API multimédia, auquel cas elle fait du très bon travail en 2D.
* En conjonction avec OpenGL auquel cas elle sert plus de panel de fonctions à la façon de GLUT. Ok, elle gère quand même 'un poil' plus de choses que GLUT, mais c'est un peu le principe, non ?
Non, ben là, y a un truc que t'as pas bien vu : c'est pas parce que tu utilises opengl que les api son/réseau/threads... de SDL disparaissent.
Le troll C vs C++ n'est pas nouveau
Et comme prévu, on m'a déjà demandé si je m'étais drogué, pour mon post précédent ;) Je suis le genre inconditionnel de c++, mais là, aucun intérêt. C'est tout. Si tu trouves que c'est balancé froidement, relis... non pardon, lis mon post précédent.
Effectivement, c'est un poil plus lourd, et parfois 'overkill'
Hmm... t'es sûr que t'as bien digéré ta bible ? Ou alors tu ne t'abreuves pas au Saint Stroustrup's TC++PL, 3rd ed (1) ! Allez, cours de rattrapage : « à fonctionnalité égale, C++ n'est pas moins efficace que C ».
(1) http://www.research.att.com/~bs/3rd.html(...)
[^] # Re: paradigmes divergents !
Posté par beagf (site web personnel) . Évalué à 1.
Une chose qui m'énerve profondement dans la majoritée des système a forum comme ici, c'est le manque d'un minimum de respect de la part de certaines personnes.
Ok, il n'y a dans ton message aucune accusation directe, mais en le lisant on peut sentir un certains dédain, voir mépris.
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.
Il me semble au contraire qu'il a très bien compris la différence entre les deux, ce qu'il cherche c'est un wrapper C++, à la fois pour OpenGL et pour des libs annexes, pour au final obtenir un système de développement de jeux tel que DirectX. (OpenGL étant plus à comparer avec Direct3D)
Toute petite réponse : Carmack codait déjà quand j'étais tout petit (allez, « presque »).
Mais Carmack à lui aussi été petit malgré ce que prétend la légende. De plus ce genre d'attaque est pitoyable, au moins dans le monde informatique, quand on voit la qualitée des contributions de certains. Dans pas si longtemps que ça on vera des codeur qui n'aurons pas connus le milénnaire précédant.
De plus, rien ne te permet de porter cette accusation, Nicolas a peut-être 60ans, il a developpé pendant 35 ans dans une boite privée, et fait un du DirectX sur la fin de sa carrière, et maintennant qu'il est à la retraite il veux continuer pour sa pomme sur son système libre favori.
Pour la partie sur le C vs C++
Comme d'hab, je ne dirais qu'une chose chacun ses goûts. Si il veux developper son truc pour lui, ou même un truc destiner aà la communautée, autant qu'il le fasse dans un langage qu'il aime, ça augmente les chances qu'il le maintienne plus tard et si ça ne te plait pas tu ne l'utilise pas.
De plus tu prétend que le C++ n'est pas adapté à l'OpenGL, que c'est des truc à faire avec du bas niveau, mais dans ce cas là il faut passer directement à l'assembleur. (si si on peut faire de l'OpenGL en asm) Mais pourquoi utiliser OpenGL, alors que l'on dispose toujours du fantastique ModeX du VGA.
OK j'abuse, mais Nicolas a surement de bonne raisons (en tout cas pour lui) de choisir le C++, donc au lieu de critiquer son choix le mieux aurait été de lui expliquer de manière réellement constructive pourquoi tu n'aurais pas fait le même.
Je trouve qu'il est dommage de gacher aussi bêttement un post qui contiens pourtant aussi des propos interressants mais noyé dans le reste...
[^] # Re: paradigmes divergents !
Posté par Frédéric COIFFIER . Évalué à 2.
Pour avoir jeter un coup d'oeil à DirectX ou plutôt Direct3D et même avoir acheté un bouquin, je n'ai rien compris ! Certes, je n'ai pas trop insisté mais le bouquin était inbuvable, la doc idem... Bref, un peu rebutant.
Alors que l'OpenGL, c'est tellement simple (mais j'avoue n'avoir pas poussé très loin mes investigations) et on s'y met très vite que l'on est bien content que ce soit en C !
http://nehe.gamedev.net/(...)
Idem pour SDL ! Quelques fonctions bien fouttues que l'on appelle comme on veut ! Quelle souplesse !
Mais perso, quand je programme, j'aime bien structurer les choses et c'est pourquoi je ne peux pas me passer du C++.
Donc, j'encapsule tout dans des objets pour mes usages propres et c'est très pratique !
Bref, la souplesse du C permet aussi de profiter du C++ ! Alors que l'inverse ne serait pas vrai. (Et on peut étendre ça à Python, Ruby et l'utiliser avec Gtk, Qt, etc...)
Sinon, pour éviter d'avoir à réimplémenter des wrappers, il faudrait voir ce qui existe et je pense qu'il y a des tonnes de choses. Reste à faire des benchmarks sur la maturité, les fonctionnalités, les domaines d'applications et avoir des retours !
Il y a effectivement des choses comme Ogre mais je ne sais pas si c'est seulement un moteur 3D ou si Ogre permet d'accéder aux autres fonctions multimédias (audio, "2D", entrées/joystick, etc..)
[^] # Re: paradigmes divergents !
Posté par gourgou . Évalué à 1.
manque d'un minimum de respect
on peut sentir un certains dédain, voir mépris (dans mon tu n'as pas bien compris la différence)
Non, aucun manque de respect, aucun dédain, aucun mépris. Je n'ai pas de préjugé négatif quant au fait que quelqu'un ne sache pas un truc ou quant au fait de lui faire remarquer. A l'opposé, ça ne flatte pas mon ego d'expliquer à quelqu'un pourquoi je pense différemment.
ce qu'il cherche c'est un wrapper C++, à la fois pour OpenGL et pour des libs annexes
C'était la réflexion finale de mon post. J'ai l'habitude de préserver mon sens (ordre) de raisonnement plutôt que de refaire le milieu au moment où j'arrive à la fin. Ca peut effectivement dérouter, mais dans ce cas, je ne trouve pas que ça crée de contradiction.
Mais Carmack à lui aussi été petit malgré ce que prétend la légende. [...] De plus, rien ne te permet de porter cette accusation, Nicolas a peut-être 60ans, il a developpé pendant 35 ans [...]
Là, de une, typiquement, j'ai remplacé un smiley par une touche d'humour (Toute petite réponse). De deux, je faisais référence à l'expérience du monsieur dans le domaine précis dont on parle. Un gars arrive et dit « je suis nouveau et je comprends pas comment font les dinos », ben la réponse est « c'est des dinos ». Il reste bien entendu que ces même dinos ont aussi débuté un jour, qu'à l'époque ils ont cherché, et qu'ils sont passés par l'équivalent d'alors du journal de Nicolas... Je trouvais juste que cette explication, ça faisait beaucoup de mots pour pas grand chose, d'où l'ellipse.
Si il veux developper son truc
Je ne crois pas vraiment qu'il ait, là tout de suite, la moindre intention de se jeter dans la réalisation d'un équivalent OpenGL. ;)
De plus tu prétend que le C++ n'est pas adapté à l'OpenGL
Je ne prétends pas, puisque j'ai détaillé.
si si on peut faire de l'OpenGL en asm
Et là, j'ai l'idée qu'on n'est pas du tout sur la même longueur d'onde (ceci sans insinuer, bien sûr, que la mienne est plus longue que la tienne ;-P ). Quand je dis « c++ ne présente aucun avantage pour opengl », je parle de la forme de l'api ; pas du langage de l'appelant !
Donc Nicolas, des fois que je me sois mal exprimé sur ce point, sache que tu n'es pas tout seul à coder en c++ des applis qui utilisent opengl. Là dessus je n'ai, évidemment, rien à redire. Mon propos était « une alternative "interfacée en c++" équivalente en termes de fonctionnalités à opengl, je ne vois pas bien ».
au lieu de critiquer son choix le mieux aurait été de lui expliquer de manière réellement constructive pourquoi tu n'aurais pas fait le même
< mode=ironie > <!--si si, quand même, mais avec les bonnes balises> Tu aurais pas décroché dès que j'ai dit « ça va être technique » (1), des fois ? < /mode >
[Mais bon, que quelqu'un m'inutile, svp : débattre de la forme ne sert pas le fond. Tout ça ne répond pas à la question]
--
(1) D'ailleurs, « ça va être tout noir ! »
[^] # Re: paradigmes divergents !
Posté par Anonyme . Évalué à 1.
ça fait du bien de voir que quelqu'un m'a compris !
J'ai 19 ans, je code depuis environ 5 ans, 3 ans de cpp, 1 an de DirectX, et je préfère jusque là l'interface DirectX à celle OpenGL. Chacun ses goûts, comme toujours, mais pour ma part, une interface orientée objet, tirant partie des mécanismes C++, de la STL, reste bien préférable.
On peut se taper dessus longtemps comme ça, car de tte manière personne n'a vraiment raison, vu que tout dépend du choix de chacun.
Histoire quand même de ne pas passer pour un idiot, ma question "comment fait Carmack", n'est pas une admiration naïve du monsieur, en attendant une méthode miracle, mais plutôt une interrogation simple.
Bien sûr, il ne s'agit pas de bêtement copier, mais si Carmack, ou en général aucun développeur professionnel (je parle des superproductions type NeverwinterNights, Unreal Tournament, Doom 3...) n'utilise SDL, par exemple, c'est bien qu'il y a une raison.
De même, s'ils utilisent telle ou telle API audio (je dis ça au hasard), c'est bien qu'elle a quelque chose qui fait que c'est avantageux de l'utiliser elle plutôt qu'une autre.
De la même manière, on peut se demander pourquoi les jeux professionnels récents sont tous en C++, et pas en C...... (ok, là je suis méchant, je retombe dans le troll)
Enfin bon, vais m'arrêter là :/
[^] # Re: paradigmes divergents !
Posté par Stephane Marchesin (site web personnel) . Évalué à 2.
Franchement, tu pourrais te documenter avant de sortir de telles âneries. Sur tes 3 exemples, tu t'es planté pour deux ! En effet, NeverwinterNights et Unreal Tournament 2003/2004 utilisent SDL. D'ailleurs la plupart des jeux portés par Ryan Gordon utilisent SDL (America's Army, Postal 2, Serious Sam 2, Army Ops...).
[^] # Re: paradigmes divergents !
Posté par Anonyme . Évalué à 1.
Donc SDL serait un investissement valable, même au niveau professionnel.
# \_o<
Posté par doublehp (site web personnel) . Évalué à 2.
eh non ... Carmak est intelligent.
Tu vois Java ? c est bien, c est portable, c est lent.
Karmac s est donc dit, depuis Quake 2 ... y a deux bonnes idees dans Java: Bien+portable. Cela est inherent a une qualite essentielle: la machine virtuelle: VM.
Loin de moi l idee que Quanke/Doom est inspire, ou meme base sur Java, mais voila ou je veux en venir:
Carmak ecrit une VM en C, ca pese quoi ... 800K tout compile, ca se code vite fait, et dedans, tu ecris ton propre langage, ton compilo, tes APIs ... et tu est le roi chez toi.
Porter ton jeux ? ben tu porte juste la VM. Bref, tu porte ni ton langage, ni ton API, juste la VM.
Cf les sources de Quake2 qui sont open.
[^] # Re: \_o<
Posté par benoar . Évalué à 2.
D'abord l'histoire de la VM n'est arrivé qu'avec Quake 3. Pour quake 2, on compile son dll et son .so pour chaque archi.
En plus, la partie interprétée par la VM n'est QUE la logique du jeu. Le moteur lui est compilé directement pour la plateforme, et écrit en C (pour Quake 3 du moins).
Ce besoin d'une VM pour la logique du jeu vient (d'apres moi) du fait que les développeurs de mods n'ont pas toujours accès à toutes les plateformes où tourne Q3, alors pour éviter de n'avoir que des mods pour windows (plateforme majoritaire chez les moddeurs), il a créé ce système de VM. Bon, au final ca a quand meme causé qq problèmes avec les windowsiens qui se plaignaient de la lenteur de la VM par rapport à un dll natif (lenteur relative, mais dans un jeu où pour beaucoup garder son compteur de fps à 125 est très important, ça compte).
Ensuite, son propre langage pour la VM, bah c'est en fait du C. Je sais pas si toutes les bidouilles du C sont permises, mais dans la très grande majorité des cas (i.e. j'ai jamais entendu parlé de problèmes de ce genre) ça tourne nickel (carmack a appris les problèmes d'un "presque C" avec Quake1 et le QuakeC).
Donc porter son jeu n'a pas été aussi simple. En fait, pour répondre à l'interrogation de Nicolas, Carmack a créé sa propre API d'abstraction des différentes parties de l'interaction (clavier, souris, vidéo, etc...). Elle tourne au dessus de DirectX sous windows (ce qui rend cette partie simple car DX fait la majorité du boulot) et d'API plus bas niveau sous nux (accès direct à X11, et OpenGL). Il utilise quand meme OpenGL sous windows, DirectX lui sert seulement pour le reste.
Donc "Use the source, Luke!" et va voir le code de Q2 comme dis plus haut. Par contre si tu t'intéresse à la VM de Q3, va falloir attendre car Carmack n'a toujours pas donné le code source; bien que promis à noel, le cadeau a été repoussé...
# 3D avec SDL
Posté par Sébastien Munch . Évalué à 2.
http://www.libsdl.org/index.php(...)
De toute façon, SDL correspond au même usage que DirectX... sauf que c'est multi-plateformes...
# python
Posté par mammique . Évalué à 1.
- python-opengl
- python-sdl (i/o et integration OGL)
- python-gst (bindings GStreamer, sortie SDL, OGL, etc.)
Et si t'as besin de bonnes perfs, il existe un compilo python performant qui zappe l'interpréteur.
[^] # Re: python
Posté par Sylvain (site web personnel) . Évalué à 1.
Ou sinon je viens bien que l'on mexplique avec quel optimisation sur cxfreeze.
[^] # Re: python
Posté par mammique . Évalué à 1.
# Crystal space
Posté par Hugo Mercier (site web personnel) . Évalué à 3.
http://www.crystalspace3d.org/(...)
# nebula engine
Posté par Fred BM . Évalué à 1.
Il est développé par radon lab et d'autre programmeur indépendant. Actuellement ils font la version 2. Le premier moteur étais utilisé par le jeux de radon labs project nomads (2002). il semble tourné sur Linux, Windows en open GL et/ ou direct X.
Le moteur fais tout et recoit en entrés des fichiers de descriptions de scene écrit soit en Lua, soit en python soit en TCL. Tu peut aussi attaquer directement l'api en C++. Bon faut prendre ce que je dis avec des pincettes mais si t'es motivé je pense qu'il est celui qui offre le plus de possibilité et est le plus aboutie. J'ai crus comprendre qu'il developpe aussi une extension à eclipse pour programmer directement le jeu a l'aide de la plateforme de dev.
Actuellent Radons labs le developpe en partie pour son futur jeu Schwarzenberg.
Qu'est ce qu'il manque : une adresse
http://www.radonlabs.de(...)
une autre adresse le moteur open source. http://nebuladevice.cubik.org/(...)
# irrlicht et raydium
Posté par foulmetal canette (site web personnel) . Évalué à 2.
http://irrlicht.sourceforge.net/(...)
Autrement, vu à la linux party à Nantes, raydium, un projet francophone (nantais ?), ça à l'air sympa :
http://raydium.yoopla.org/wiki/Raydium(...)
# OpenGL c'est bon mangez-en
Posté par GuieA_7 (site web personnel) . Évalué à 1.
OpenGL doit plutôt être comparé à Direct3D qu'à DirectX. Si tu veux l'équivalent de ce dernier tu devras faire du OpenGL + SDL. Ca peut te paraître bizarre toi qui est habitué à une API qui fait tout, mais le duo OGL/SDL marche vraiment pas mal du tout, et c'est ce qui est souvent utilisé pour les jeux pros portés sous GNU/Linux. Je ne peux que t'encourager à essayer : j'espère que tu ne seras pas déçu. Persévères, tu verras ces 2 API sont vraiment bien faites; et pour ne rien gacher sont trés portables.Pour finir je trouve que le choix du C pour OGL me parait pertinent, notamment avec la facilité de faire des wraps pour à peu prés tous les langages existants.
Personellemnt je pense que le choix du C++ pour faire un jeu 3D est un trés bon choix, mais il n'y a vraiment aucun problème à utiliser des API en C : tout aussi objet que soit l'API de DirectX, on fini toujours par la wrapper de toute les façons. Et wrapper OGL n'est pas franchement plus dur. D'ailleurs voici un lien vers une série d'articles qui montre comment faire un moteur 3D qui utilise indifféremment OGL ou Direct3D. L'auteur aborde le fait que OGL ne soit pas orienté objet, mais que ca ne pose pas de réel problème :
http://loulou.developpez.com/tutoriels/moteur3d/(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.