En ce qui concerne PlaneShift, il n'y a pas de client binaire officiel et il est interdit de jouer avec un client non-officiel, à cause des restrictions de la licence sur les données. Donc on peut difficilement dire qu'il est compatible Linux pour l'instant, même si le code source est supposé l'être.
Je viens de lire la licence PlaneShift et de ce que je comprends, il est interdit de distribuer les données sans l'accord de l'équipe de PlaneShift. Ça veut dire qu'on n'a de toute façon pas le droit de distribuer un binaire qui fonctionne sans leur autorisation, puisqu'il a besoin des données.
Il est aussi dit dans cette licence qu'il est interdit de faire quoi que soit avec ces données (même les afficher !) à part les utiliser en jouant avec un client PlaneShift officiel sur un serveur PlaneShift officiel. Ça veut donc dire aussi qu'on n'a même pas le droit de jouer à ce jeu avec une version qu'on aurait compilé soi-même.
Quand je relis le titre de la dépêche (« Un MMORPG libre »), je ne peux pas m'empêcher de sourire...
Par contre je ne trouve pas quelle parties du client est concernée.
Ben ça semble évident, il s'agit des sources du moteur (NeL) qu'il utilisent pour le client Ryzom. Ça gère notamment la 3D, le son, le réseau et l'IA, càd tout ce qui fait l'infrastructure technique du jeu.
Absolument et c'est ce que je faisais quand j'en avait encore le temps. Surtout qu'il faut le faire pour chaque distrib.
Visiblement il y a vraiment un truc qui m'échappe, pourquoi cette obstination à dire qu'il faut faire une compilation pour chaque distrib ?
Les jeux propriétaires sous Linux sont fournis en version binaire et il y en a une version unique qui fonctionne pour toutes les distribs. Il suffit de compiler statiquement et de ne lier dynamiquement qu'à des librairies de bases du système (glibc, Xlib, OpenGL/GLX).
Je vois vraiment pas où est le problème, c'est exactement comme pour la version Windows. Et si vous voulez raffiner le truc pour qu'il soit plus présentable, vous utilisez le Loki Installer comme les jeux propriétaires. Vu le nombre de releases par an du projet, c'est quand même pas un travail titanesque.
Presque tous les devs sont sous Linux ; alors pas intéressé par une version Linux....
Dans ce cas, pourquoi ne fournissent-ils pas au moins un tarball des sources, ça demande encore moins d'efforts que de préparer des binaires Windows. D'autant que j'imagine que la version CVS doit continuer à évoluer et ne sera plus forcément aussi stable qu'à la version 0.3.
Par contre, ils sont intéressés par l'avancement du développement.
La priorité au développement ne les empêche pas de fournir une version compilée sous Windows visiblement. Je ne vois pas pourquoi ils ne fournissent pas aussi une version Linux compilée, c'est normalement exactement la même procédure.
L'impression que ça donne, c'est qu'ils n'ont vraiment pas envie que des Linuxiens testent leur jeu. Ben ils peuvent être satisfaits, je pense que ça marche très bien comme tactique...
J'ai quand même du mal à comprendre d'où peuvent venir ces problèmes de dépendances. Que le code de PS, Cal3D et CS bouge souvent je peux comprendre, mais les bibliothèques qu'ils utilisent sont quand même plutôt stables en général.
Au pire, pourquoi ne pas fournir également des versions statiques de toutes les autres librairies qui posent problème ? C'est pas ce que les développeurs font pour la version Windows ?
Il y en a 4 en tout, le premier avait pour titre INSTALLATION. C'est clair qu'avec un comportement pareil, ça ne donne absolument pas envie de l'aider.
J'imagine que les développeurs doivent la compiler de temps en temps la version Linux, non ? Ils ne pourraient pas distribuer un binaire compilé statiquement qui ne soit linké qu'à la Xlib et à OpenGL/GLX. Ou un binaire lié dynamiquement fourni avec les .so des libs utilisées ?
Ça me paraît quand même pas être un effort énorme pour un développeur et c'est une pratique plutôt répandue dans les projets libres (Blender par exemple). Charge ensuite aux personnes intéressées de faire un paquet pour leur distribution avec ces binaires. Ce qui serait quand même plus simple que de devoir repartir des sources.
Tiens, à propos des sources de Quake, celles de Quake 3 n'ont pas été rendues disponibles sous GNU GPL avant la fin de l'année 2004 comme prévu. Et à priori ça va pas être pour tout de suite non plus : http://www.armadilloaerospace.com/n.x/johnc/Recent%20Updates(...)
Pour Ryzom, à priori seul le moteur est libre (NeL), pas le code source de l'application proprement dite. Pour Planeshift, tout le code source est libre (le moteur 3D Crystal Space était déjà libre), donc ça fait quand même une petite différence. Et puis Ryzom n'est pas encore porté sous Linux me semble-t-il.
Concernant Quake 3, beaucoup de gens quand il est sorti considéraient que ce n'était qu'une démo technologique et que le jeu en lui même n'avait pas grand intérêt, tout comme pour Doom 3. Qui vivra verra...
Il existe aussi pas mal de projets de MMORPG libres en cours de développement, une petite recherche avec le mot-clé "mmorpg" retourne quelques résultats sur The Linux Game Tome : http://happypenguin.org/(...)
C'est bizarre que ta carte graphique ne fonctionne pas avec un port AGP 8x, il me semblait qu'il y avait compatibilté ascendante dans ce domaine.
Sinon, si tu veux une carte graphique minimale qui fait tourner à peu près correctement les jeux actuels sans te ruiner, je te conseille une GeForce 5200 (50-60 ¤). Ca rame pas mal sur Doom 3 par contre (10-15 images/s), mais ça tourne correctement avec la plupart des autres jeux (Quake 3, Enemy Territory, Unreal Tournament 2003 et 2004, FarCry avec Cedega, tous les jeux libres que j'ai testé). Cela dit, elle risque d'être rapidement dépassée et trop juste pour les jeux à venir.
L'inconvénient de cette carte est qu'il te faudra utiliser un driver propriétaire qui n'est pas intégré dans la plupart des distributions puisque non libre. Mais il s'installe quand même facilement et il existe aussi des paquets Debian/unstable même si je les trouve moins pratiques que le driver officiel.
Si tu veux un modèle un peu au dessus, la GeForce 5700 (pas LE) et la GeForce 5900 XT ont très bonne réputation, mais je pense que tu risques de trouver les tarifs assez prohibitifs.
À priori je pense qu'il vaut de toute façon mieux choisir une carte NVIDIA qu'une ATI à cause de la qualité des drivers, mais je n'ai jamais eu d'ATI entre les mains pour tester. Il me semble que certains modèles ATI bas de gamme sont supportés par le driver libre, mais je ne sais pas ce que valent ces cartes ni leurs drivers.
Il y a pourtant des jeux, que ca soit dans le libre ou le proprio, qui ont fait le choix de python et qui s'en portent tres bien... (tres recemment, vampire:bloodlines)
Dans Vampire Bloodlines, Python est utilisé pour faire du scripting. C'est ce que je disais plus haut :
« je pense que Python peut effectivement être adapté comme langage de script ou pour faire des jeux simples »
Ca peut justement repondre a la plupart des problematiques du developpement de jeux video parce que c'est un framework complet, qui permet de faire un tas de choses rapidement...
Je comprends qu'on soit très attaché à Python et qu'on ait envie de l'utiliser partout, mais non, je ne pense pas qu'il soit adapté à toutes les problématiques de développement de jeux vidéo. Les fans de Java ont souvent le même problème d'ailleurs...;)
Après, une conscience, on en a une ou pas, et sur les sujets qu'on veut. Je n'ai rien à dire la dessus.
Visiblement si, tu as quelque chose à dire là dessus, puisque tu te permets de donner des leçons de morale et de dire aux autres quoi penser. Ce que les gens font de leur conscience, c'est pas ton problème, et je me demande qui tu es pour dire ce qui est bien ou mal, et déterminer les jeux auxquels les autres doivent jouer ou pas. Surtout que t'as même pas essayé le jeu, donc tu n'as aucune idée du message qui y est véhiculé, si toutefois il y en a un. Tu bases toute ton argumentation sur des suppositions, et je trouve ça bien léger.
Moi non plus d'ailleurs je n'ai pas essayé le jeu, mais je dis pas aux autres ce qu'ils doivent penser à ce sujet.
Je les ai démarqués (super ton jeu de mot :) parce que c'est une catégorie bien représentée, on ne peut pas en dire autant d'autres types de jeux de sport comme le rugby.
Il n'y a même pas une sortie par an et chaque nouvelle version est à peu près aussi catastrophique que la précédente, mais avec plus de couleurs et de polygones. Et oui, merci pour eux, je les essaye régulièrement les jeux de rugby (de simu, pas de gestion), et ça me navre à chaque fois...
D'autre part, je n'ai pas mis l'ensemble des types de jeux auxquels je pensais, sinon mon post aurait été _beaucoup_ plus long.
Marrant ton procès d'intention, c'est parce que pour toi aimer le foot _ET_ le rugby te semble incompatible ?
Python est peut être lent, mais le moteur 3D de Slune est (ou était, il est peut etre en Pyrex(C+python)maintenant) écrit en C
Le moteur utilisé par Slune (Soya) est effectivement écrit en Python/Pyrex (donc converti en C et compilé) comme tu le supposais. Il était auparavant écrit en Python pur et peut-être en C avant ça.
C'est marrant sinon, le premier argument avancé par l'auteur de Pyrex par rapport à Python est la lenteur : http://ldots.org/pyrex-guide/(...)
et seul le jeu en lui même est en python.
Concernant l'utilisation de Python pour écrire le jeu proprement dit, il y a une question sur la FAQ de Soya (http://home.gna.org/oomadness/en/soya/faq.html(...) ) demandant si Python n'est pas trop lent pour les jeux 3D, ce qui montre que la question est à priori légitime.
L'auteur répond qu'il pense que non et il argumente en disant que dans ses essais, 80% du temps est passé dans le code 3D et donc que l'utilisation d'un autre langage ne permettrait d'améliorer que les 20% restants.
D'une part, ça montre que Python n'est pas forcément une solution optimale par rapport à d'autres langages puisqu'on sacrifie de 0 à 20% des performances. D'autre part, je doute qu'il ne reste que 20% à optimiser pour des jeux comprenant de l'intelligence artificielle, de la physique, du réseau, des ombres portées ou des calculs 3D complexes.
Il me semble aussi (mais je ne suis pas sûr) que les tâches du processeur graphique peuvent se faire partiellement en parallèle des tâches du processeur principal. Si c'est le cas, ça pourrait créer un goulet d'étranglement dans la partie Python qui ralentirait l'ensemble. À vérifier...
Bref, je pense que Python peut effectivement être adapté comme langage de script ou pour faire des jeux simples en 3D (tout comme Java, Basic ou Perl), mais je ne pense pas que ça puisse répondre à toutes les problématiques de développement de jeux vidéo.
Oui, mais on peut se demander si le succès aurait été le même sans l'appât technologique. En d'autres termes, si Toy Story avait été fait en dessin animé classique, son succès aurait-il été le même?
Je ne sais pas s'il aurait eu le même succès, mais on peut aussi se demander si Wallace et Gromit aurait eu autant de succès s'il avait été fait en animation 2D traditionnelle, ou si Blanche neige serait restée dans les annales si ça avait été un "vrai" film.
Je pense que dans certains cas, le support et l'histoire se marient parfaitement. C'est le cas pour certains dessins animés, certains films en pâte à modeler et certains films en 3D. Mais je ne crois pas que l'utilisation d'une nouvelle technique soit forcément préjudiciable à l'intérêt d'un nouveau film ou d'un nouveau jeu vidéo ou qu'elle en fasse un produit éphémère.
Tiens au fait, tant que j'y pense, n'oublions pas que même le plublic le plus jeune et le plus hype ne crache pas sur un jeu tout con tout moche, y'a qu'à voir ce qui tourne sur les téléphones portables, c'est rarement de la 3D en 1600x1200, hé hé hé 8-)
Avec la PSP qui vient de sortir, ça risque de changer la donne assez rapidement. Et puis je sais pas si t'as remarqué, mais on est déjà loin des clônes de jeux d'arcade des années 80 dispos sur les premiers Nokia. Heureusement qu'il y a encore Nintendo, qui peut se permettre de sortir des jeux 2D "old-school" comme WarioWare ou Paper Mario sans que les gamins crient au scandale...
GL-117 :
un simulateur de combat aérien orienté arcade en 3D, avec un mode entraînement et plusieurs missions. Le bruit et le mode de fonctionnement de la mitrailleuse sont un peu agaçants mais sinon c'est très sympa à jouer.
Cannon smash :
un jeu de ping-pong en 3D jouable en réseau. Pas très facile à prendre en main mais ça vient au bout d'un moment. Et un concept et une maniabilité assez originaux.
Foobillard :
un jeu de billard en 3D plutôt bien fait.
Heroes :
un clone de nibbler (serpentin) très coloré, un peu plus évolué et jouable à plusieurs.
Powermanga :
un sympathique shoot'em up. Difficile de s'arrêter quand on a commencé une partie...
Pysol :
un excellent jeu de cartes regroupant un très grand nombre de variantes, dont les célèbres Solitaire et FreeCell.
Cube :
un FPS façon Quake 2 sous license BSD. Pas forcément aussi sympa que Quake 2 mais libre néanmoins.
Pas encore essayé, mais ça a l'air vraiment pas mal
Et pour cause, il n'est pas encore jouable.
En fait, le projet d'amélioration de TuxKart était au point mort depuis plusieurs mois et n'est toujours pas terminé. L'auteur original a dit qu'il supprimerait les modifications apportées au CVS parce qu'il n'était pas d'accord avec ce qui avait été fait. Le fork a été crée pour ne pas perdre le travail effectué.
[^] # Re: Y'a du monde qui y joue ?
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 5.
[^] # Re: Différence entre le jeux et les données ?
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 2.
Tu fais exprès ?
[^] # Re: Planeshift fonctionne parfaitement sous Linux
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 6.
Il est aussi dit dans cette licence qu'il est interdit de faire quoi que soit avec ces données (même les afficher !) à part les utiliser en jouant avec un client PlaneShift officiel sur un serveur PlaneShift officiel. Ça veut donc dire aussi qu'on n'a même pas le droit de jouer à ce jeu avec une version qu'on aurait compilé soi-même.
Quand je relis le titre de la dépêche (« Un MMORPG libre »), je ne peux pas m'empêcher de sourire...
[^] # Re: Différence entre le jeux et les données ?
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 1.
Ben ça semble évident, il s'agit des sources du moteur (NeL) qu'il utilisent pour le client Ryzom. Ça gère notamment la 3D, le son, le réseau et l'IA, càd tout ce qui fait l'infrastructure technique du jeu.
[^] # Re: Planeshift fonctionne parfaitement sous Linux
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 2.
Visiblement il y a vraiment un truc qui m'échappe, pourquoi cette obstination à dire qu'il faut faire une compilation pour chaque distrib ?
Les jeux propriétaires sous Linux sont fournis en version binaire et il y en a une version unique qui fonctionne pour toutes les distribs. Il suffit de compiler statiquement et de ne lier dynamiquement qu'à des librairies de bases du système (glibc, Xlib, OpenGL/GLX).
Je vois vraiment pas où est le problème, c'est exactement comme pour la version Windows. Et si vous voulez raffiner le truc pour qu'il soit plus présentable, vous utilisez le Loki Installer comme les jeux propriétaires. Vu le nombre de releases par an du projet, c'est quand même pas un travail titanesque.
[^] # Re: Planeshift fonctionne parfaitement sous Linux
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 4.
Dans ce cas, pourquoi ne fournissent-ils pas au moins un tarball des sources, ça demande encore moins d'efforts que de préparer des binaires Windows. D'autant que j'imagine que la version CVS doit continuer à évoluer et ne sera plus forcément aussi stable qu'à la version 0.3.
La priorité au développement ne les empêche pas de fournir une version compilée sous Windows visiblement. Je ne vois pas pourquoi ils ne fournissent pas aussi une version Linux compilée, c'est normalement exactement la même procédure.
L'impression que ça donne, c'est qu'ils n'ont vraiment pas envie que des Linuxiens testent leur jeu. Ben ils peuvent être satisfaits, je pense que ça marche très bien comme tactique...
[^] # Re: Planeshift fonctionne parfaitement sous Linux
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 2.
Au pire, pourquoi ne pas fournir également des versions statiques de toutes les autres librairies qui posent problème ? C'est pas ce que les développeurs font pour la version Windows ?
[^] # Re: Hého
Posté par Frédéric Lopez . En réponse au message :: LE SYSTEME GELE PENDANT LE DEMARRAGE ::. Évalué à 3.
[^] # Re: Planeshift fonctionne parfaitement sous Linux
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 2.
Ça me paraît quand même pas être un effort énorme pour un développeur et c'est une pratique plutôt répandue dans les projets libres (Blender par exemple). Charge ensuite aux personnes intéressées de faire un paquet pour leur distribution avec ces binaires. Ce qui serait quand même plus simple que de devoir repartir des sources.
# Ça plante pas chez moi...
Posté par Frédéric Lopez . En réponse au message plantage de firefox. Évalué à 2.
[^] # Re: Différence entre le jeux et les données ?
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 6.
[^] # Re: Différence entre le jeux et les données ?
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 6.
Concernant Quake 3, beaucoup de gens quand il est sorti considéraient que ce n'était qu'une démo technologique et que le jeu en lui même n'avait pas grand intérêt, tout comme pour Doom 3. Qui vivra verra...
# D'autres MMORPG...
Posté par Frédéric Lopez . En réponse à la dépêche Un MMORPG libre. Évalué à 5.
http://www.atitd.com/(...)
http://vendetta-online.com/(...)
Il existe aussi pas mal de projets de MMORPG libres en cours de développement, une petite recherche avec le mot-clé "mmorpg" retourne quelques résultats sur The Linux Game Tome : http://happypenguin.org/(...)
# Carte graphique
Posté par Frédéric Lopez . En réponse au message Quelle(s) carte(s) graphique + vidéo récente(s) pour Linux ?. Évalué à 3.
Sinon, si tu veux une carte graphique minimale qui fait tourner à peu près correctement les jeux actuels sans te ruiner, je te conseille une GeForce 5200 (50-60 ¤). Ca rame pas mal sur Doom 3 par contre (10-15 images/s), mais ça tourne correctement avec la plupart des autres jeux (Quake 3, Enemy Territory, Unreal Tournament 2003 et 2004, FarCry avec Cedega, tous les jeux libres que j'ai testé). Cela dit, elle risque d'être rapidement dépassée et trop juste pour les jeux à venir.
L'inconvénient de cette carte est qu'il te faudra utiliser un driver propriétaire qui n'est pas intégré dans la plupart des distributions puisque non libre. Mais il s'installe quand même facilement et il existe aussi des paquets Debian/unstable même si je les trouve moins pratiques que le driver officiel.
Si tu veux un modèle un peu au dessus, la GeForce 5700 (pas LE) et la GeForce 5900 XT ont très bonne réputation, mais je pense que tu risques de trouver les tarifs assez prohibitifs.
À priori je pense qu'il vaut de toute façon mieux choisir une carte NVIDIA qu'une ATI à cause de la qualité des drivers, mais je n'ai jamais eu d'ATI entre les mains pour tester. Il me semble que certains modèles ATI bas de gamme sont supportés par le driver libre, mais je ne sais pas ce que valent ces cartes ni leurs drivers.
[^] # Re: C'est bien joli tout ca mais...
Posté par Frédéric Lopez . En réponse au journal [Wine] Quand deux millésimes se tirent la bourre. Évalué à 3.
# Belote et Linux
Posté par Frédéric Lopez . En réponse au message Belote et Linux. Évalué à 4.
http://sourceforge.net/projects/belote/(...)
http://online-gaming.sourceforge.net/(...)
[^] # Re: Normal MAP
Posté par Frédéric Lopez . En réponse à la dépêche Blender 2.36. Évalué à 3.
Pas tout à fait quand même. Sur ce lien http://www.pinwire.com/modules.php?name=News&file=print&sid(...) on voit clairement la différence entre les deux. Le bump mapping permet essentiellement de faire un effet "bas relief", le normal mapping permet de simuler la présence de polygones supplémentaires sur un modèle simplifié. Voir également ici http://www.crytek.com/screenshots/index.php?sx=polybump&px=poly(...) pour quelques exemples de normal mapping assez impressionants.
[^] # Re: radeon 9200 suite :
Posté par Frédéric Lopez . En réponse au message au secours ! radeon 9200 et mandrake 10.1. Évalué à 2.
En même temps, le score à glxgears ne veut pas dire grand chose. Voir ce journal à ce sujet http://linuxfr.org/~ploum/14494.html(...) et notamment les commentaires http://linuxfr.org/comments/445125,1.html(...) et http://linuxfr.org/comments/453321,1.html(...)
Je pense que le score à Quake 3 (ou autre) est plus représentatif de l'usage qu'on fait généralement d'une carte 3D http://linuxfr.org/comments/448923,1.html(...)
[^] # Re: euuuuhh
Posté par Frédéric Lopez . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 2.
Dans Vampire Bloodlines, Python est utilisé pour faire du scripting. C'est ce que je disais plus haut :
« je pense que Python peut effectivement être adapté comme langage de script ou pour faire des jeux simples »
Je comprends qu'on soit très attaché à Python et qu'on ait envie de l'utiliser partout, mais non, je ne pense pas qu'il soit adapté à toutes les problématiques de développement de jeux vidéo. Les fans de Java ont souvent le même problème d'ailleurs...;)
[^] # Re: American Army ?!
Posté par Frédéric Lopez . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 4.
Visiblement si, tu as quelque chose à dire là dessus, puisque tu te permets de donner des leçons de morale et de dire aux autres quoi penser. Ce que les gens font de leur conscience, c'est pas ton problème, et je me demande qui tu es pour dire ce qui est bien ou mal, et déterminer les jeux auxquels les autres doivent jouer ou pas. Surtout que t'as même pas essayé le jeu, donc tu n'as aucune idée du message qui y est véhiculé, si toutefois il y en a un. Tu bases toute ton argumentation sur des suppositions, et je trouve ça bien léger.
Moi non plus d'ailleurs je n'ai pas essayé le jeu, mais je dis pas aux autres ce qu'ils doivent penser à ce sujet.
[^] # Re: Sérieusement...
Posté par Frédéric Lopez . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 2.
Il n'y a même pas une sortie par an et chaque nouvelle version est à peu près aussi catastrophique que la précédente, mais avec plus de couleurs et de polygones. Et oui, merci pour eux, je les essaye régulièrement les jeux de rugby (de simu, pas de gestion), et ça me navre à chaque fois...
D'autre part, je n'ai pas mis l'ensemble des types de jeux auxquels je pensais, sinon mon post aurait été _beaucoup_ plus long.
Marrant ton procès d'intention, c'est parce que pour toi aimer le foot _ET_ le rugby te semble incompatible ?
[^] # Re: euuuuhh
Posté par Frédéric Lopez . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 2.
Le moteur utilisé par Slune (Soya) est effectivement écrit en Python/Pyrex (donc converti en C et compilé) comme tu le supposais. Il était auparavant écrit en Python pur et peut-être en C avant ça.
C'est marrant sinon, le premier argument avancé par l'auteur de Pyrex par rapport à Python est la lenteur : http://ldots.org/pyrex-guide/(...)
Concernant l'utilisation de Python pour écrire le jeu proprement dit, il y a une question sur la FAQ de Soya (http://home.gna.org/oomadness/en/soya/faq.html(...) ) demandant si Python n'est pas trop lent pour les jeux 3D, ce qui montre que la question est à priori légitime.
L'auteur répond qu'il pense que non et il argumente en disant que dans ses essais, 80% du temps est passé dans le code 3D et donc que l'utilisation d'un autre langage ne permettrait d'améliorer que les 20% restants.
D'une part, ça montre que Python n'est pas forcément une solution optimale par rapport à d'autres langages puisqu'on sacrifie de 0 à 20% des performances. D'autre part, je doute qu'il ne reste que 20% à optimiser pour des jeux comprenant de l'intelligence artificielle, de la physique, du réseau, des ombres portées ou des calculs 3D complexes.
Il me semble aussi (mais je ne suis pas sûr) que les tâches du processeur graphique peuvent se faire partiellement en parallèle des tâches du processeur principal. Si c'est le cas, ça pourrait créer un goulet d'étranglement dans la partie Python qui ralentirait l'ensemble. À vérifier...
Bref, je pense que Python peut effectivement être adapté comme langage de script ou pour faire des jeux simples en 3D (tout comme Java, Basic ou Perl), mais je ne pense pas que ça puisse répondre à toutes les problématiques de développement de jeux vidéo.
[^] # Re: Sérieusement...
Posté par Frédéric Lopez . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 3.
Je ne sais pas s'il aurait eu le même succès, mais on peut aussi se demander si Wallace et Gromit aurait eu autant de succès s'il avait été fait en animation 2D traditionnelle, ou si Blanche neige serait restée dans les annales si ça avait été un "vrai" film.
Je pense que dans certains cas, le support et l'histoire se marient parfaitement. C'est le cas pour certains dessins animés, certains films en pâte à modeler et certains films en 3D. Mais je ne crois pas que l'utilisation d'une nouvelle technique soit forcément préjudiciable à l'intérêt d'un nouveau film ou d'un nouveau jeu vidéo ou qu'elle en fasse un produit éphémère.
Avec la PSP qui vient de sortir, ça risque de changer la donne assez rapidement. Et puis je sais pas si t'as remarqué, mais on est déjà loin des clônes de jeux d'arcade des années 80 dispos sur les premiers Nokia. Heureusement qu'il y a encore Nintendo, qui peut se permettre de sortir des jeux 2D "old-school" comme WarioWare ou Paper Mario sans que les gamins crient au scandale...
# D'autres jeux sympas...
Posté par Frédéric Lopez . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 3.
un simulateur de combat aérien orienté arcade en 3D, avec un mode entraînement et plusieurs missions. Le bruit et le mode de fonctionnement de la mitrailleuse sont un peu agaçants mais sinon c'est très sympa à jouer.
Cannon smash :
un jeu de ping-pong en 3D jouable en réseau. Pas très facile à prendre en main mais ça vient au bout d'un moment. Et un concept et une maniabilité assez originaux.
Foobillard :
un jeu de billard en 3D plutôt bien fait.
Heroes :
un clone de nibbler (serpentin) très coloré, un peu plus évolué et jouable à plusieurs.
Powermanga :
un sympathique shoot'em up. Difficile de s'arrêter quand on a commencé une partie...
Pysol :
un excellent jeu de cartes regroupant un très grand nombre de variantes, dont les célèbres Solitaire et FreeCell.
Cube :
un FPS façon Quake 2 sous license BSD. Pas forcément aussi sympa que Quake 2 mais libre néanmoins.
Pingus :
un clône de Lemmings plutôt bien léché.
[^] # Re: SuperTuxKart
Posté par Frédéric Lopez . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 2.
Et pour cause, il n'est pas encore jouable.
En fait, le projet d'amélioration de TuxKart était au point mort depuis plusieurs mois et n'est toujours pas terminé. L'auteur original a dit qu'il supprimerait les modifications apportées au CVS parce qu'il n'était pas d'accord avec ce qui avait été fait. Le fork a été crée pour ne pas perdre le travail effectué.