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é...
[^] # Re: \_o<
Posté par benoar . En réponse au journal Développer des jeux vidéos sous Linux ?. É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é...