Discussion :

[shenron666]

le jeu Eve online qui tient bien la route n'a pas été developpé en c++ (j'ai oublié en quel langage) pour dire que c'est quand même possible. Pour call of juarez je serais étonné que ce soit du java, mais je pense que le débat serait clos sur le fait de pouvoir utiliser java pour un jeu avec les standard actuels.

Eve Online c'est du Stackless Python
Call of Juarez c'est du C++ et apparemment java est utilisé pour le scripting

[ac_wingless]

Il y a deux présupposés curieux dans toute cette discussion, c'est que (1) C++ serait plus rapide, et que (2) ça serait donc la raison de son omniprésence dans le domaine du jeu video.

1) D'abord, je suis pas sûr que sur un jeu qui utilise les GPU à fond on soit limité par le langage. Dans un projet tout récent on devait alimenter un dispositif distant du PC (donc ficelle) avec 22 GBit/s de données (ça fait quand même 4 CD par seconde) issues d'un flux de calcul constant et nettement supérieur au téraflop. On a utilisé un GPU pour les calculs et la compression, puis un FPGA sur PCIe pour envoyer du PC vers la machine par Ethernet 1000, puis un autre FPGA standalone pour décompresser l'ethernet 1000 vers le 22 GB/s. Pendant le développement, à l'exception des tubes chargés des passages de données au travers du PCIe, faits en C#/SlimDX, la totalité du développement sur PC s'est faite sous Ruby (c'est un langage spécialisé dans la simulation au ralenti des émulateurs de calcul avec les doigts). Le passage final en C++ s'est fait pour des raisons de qualité de code, mais on n'a pas du gagné 0.1% en vitesse. Je ne sais pas à quel point cette expérience peut trouver son parallèle dans un jeu, mais c'est sûr qu'on a du utiliser DX10 et une méga carte pour jeu pour faire nos calculs, et qu'en termes de puissance de calcul 3D et de rastérisation, on était largement dans la gamme des jeux récents poussés à fond (seule une NVidia 8800 GTX passait nos besoins en perf - pour ceux qui connaissent pas, c'était presque ce qu'on pouvait acheter de plus puissant sur terre à l'époque). Après quelques tests pragmatiques, j'ai validé le choix d'un ingénieur qui préférait utiliser Ruby que C++ pour les premières phases, et ça s'est révélé sans problème pour un projet pourtant bien plus critique en termes de performances pures qu'un FPS. Je ne vois donc pas du tout pourquoi Java serait disqualifié pour des raisons de performance.

2) Par ailleurs, de très nombreux programmes qui ne sont pas du tout dans le domaine du jeu, et parmi les plus impressionnants de l'histoire, ont été développés en C++. C++ est un langage qui a ses propres mérites au niveau de la qualité de développement et de la productivité. On peut bien sûr lui préférer Java ou d'autres langages, c'est pas mon propos. Par contre, le non-dit pratiquement accepté de cette discussion selon lequel "on choisit C++ pour la performance [sic], mais que si on pouvait s'en passer (mais on peut pas pour les jeux [re-sic]), alors on passerait à Java, et que ça finira bien par arriver" me choque.

[Mat.M]

. Par contre, le non-dit pratiquement accepté de cette discussion selon lequel "on choisit C++ pour la performance [sic], mais que si on pouvait s'en passer (mais on peut pas pour les jeux [re-sic]), alors on passerait à Java, et que ça finira bien par arriver" me choque.

Moi je veux bien passer à Java mais si tu prends par exemple le SDK de Direct X c'est en C++ vu que Ms abandonne DX managed ( au profit de XNA )
Et même pour Open GL l'interface de programmation est principalement en C++ ( bien qu'ils existent des couches d'interface pour d'autres langages).

[LeGreg]

1) un jeu qui n'est pas CPU bound tournera probablement à la même vitesse, qu'il soit écrit en C++, Java ou C#. Ce type de jeu passe son temps à attendre la carte graphique. Nul besoin d'avoir Bac+36 pour comprendre que puisque le CPU n'est pas le facteur limitant, le langage et la techno utilisés n'ont pas d'effet sur le jeu lui-même.

CPU bound c'est un critère fluctuant (et un accroissement de la charge GPU autre que résolution/AA etc. entraine mécaniquement une charge CPU).

Un jeu qui n'est pas CPU bound en C++, pourrait très bien le devenir une fois programmé en java (à charge équivalente).
De plus le coût CPU moyen par frame est une des donnée du problème. Reste le problème des "hitching" du à des traitements en rafales lors de changement de zones, premier affichage etc. Ainsi que le problème de l'empreinte mémoire et la consommation d'adressage virtuel sur plateformes 32bits. Si le jeu est "short" en ressource avec une attitude conservatrice en C++ (allocations par pool, statiques, réduction des tailles de structures, etc), il est fort probable qu'il dépasserait les bornes une fois transcrit en Java (tendance à se reposer sur le GC, inflation de types "compacts", absence de plain old data structures).

[bafman]

Un jeu qui n'est pas CPU bound en C++, pourrait très bien le devenir une fois programmé en java (à charge équivalente).
De plus le coût CPU moyen par frame est une des donnée du problème. Reste le problème des "hitching" du à des traitements en rafales lors de changement de zones, premier affichage etc. Ainsi que le problème de l'empreinte mémoire et la consommation d'adressage virtuel sur plateformes 32bits. Si le jeu est "short" en ressource avec une attitude conservatrice en C++ (allocations par pool, statiques, réduction des tailles de structures, etc), il est fort probable qu'il dépasserait les bornes une fois transcrit en Java (tendance à se reposer sur le GC, inflation de types "compacts", absence de plain old data structures).

pour résumer, le C++ offre de bien meilleurs possibilités d'optimisations bas niveau que le Java

[millie]

Ce qui pourrait être intéressant de comparer, c'est la gain de temps de développement pour des jeux pas dernier cri qui peuvent tourner raisonnablement en Java ?

Surtout ici, il y a pas mal de jeu proposer qui sont très loin d'être dernier cri. Est-ce que ça ne vaudrait pas le coup de proposer de le développer en Java (si performance ça suit) si le temps de développement est plus court ?

[harold35]

Par contre, le non-dit pratiquement accepté de cette discussion selon lequel "on choisit C++ pour la performance [sic], mais que si on pouvait s'en passer (mais on peut pas pour les jeux [re-sic]), alors on passerait à Java, et que ça finira bien par arriver" me choque.

Et bien a dire vrai je ne vois pas ce qu'il y a de choquant dans cette idée. Un outil reste un outil, si demain un langage plus simple, plus rapide en production et de qualité égale apparait sur le marché, je ne vois pas ce qu'il y a d'incongru à se dire qu'il faudra migrer !

D'ailleur le point de vue que je donnais se situait au niveau du producteur, on sait tous que les programmeur pesteront tous s'il faut migrer vers un nouveau langage. Parce qu'on peste toujours quand il faut migrer... Mais le producteur ne se posera pas de question s'il peut developper un projet plus vite et aussi bien le choix sera vite fait !

Il me semble que c'est dans l'ordre naturel des choses. Le jeu vidéo n'a pour but de faire de belles applications dans un quelconque language. Le langage n'est jamais qu'un moyen pas une fin.

Et je ne pense pas que le ciel s'ouvrira pour faire descendre des anges jouant de la harpe autour de moi (si c'est arrivé a quelqu'un dites le moi) si un jour je fais une application parfaite en c++... Un langage c'est juste un outil, cela n'a rien de sacré... Enfin bref il ne faut pas vouer un culte a un langage...

[ac_wingless]

Et bien a dire vrai je ne vois pas ce qu'il y a de choquant dans cette idée.

C'est les "sic" qui sont pas clairs? Pour moi il y a 2 erreurs dans cette supposition: 1) C++ serait plus rapide que Java: faux si le jeu met suffisamment en oeuvre les GPU (cf. exemple ci-dessus où même Ruby atteint les mêmes perfs que C++, grâce à un thin wrap C# autour de DX10). et 2) Java serait plus productif que C++: faux dans un très grand nombre de contextes, hors jeu video, où le C++ est choisi. Penser que toutes ces industries qui choisissent massivement C++ ont tort est un peu court et désobligeant. Je ne vois pas pourquoi le JV échapperait à cette logique de rentabilité de développement.

Précisément, il faut être pragmatique, et ne pas idolâtrer un langage.

Edit: je ne me place que au niveau du producteur. A mon age, on est interdit de clavier, et d'ailleurs je ne me ferais plus confiance pour écrire du code dur. Je suis donc très familier avec les tiraillements entre les aspirations des programmeurs (le cas extrême: le stagiaire de 21 qui vient de lire ses design pattern et un bouquin sur Ruby en même temps ), et les soucis de rentabilité de mon équipe. Il faut trancher, et des présuppositions comme celles qui ont cours dans cette discussion peuvent à mon avis amener à des erreurs.

[harold35]

lol pardon j'avais mal interprété ta remarque, en fait j'avais compris que tu trouvais choquant que l'on puisse envisager d'abandonner le c++.

Je partage ton point de vue, même s'il me semble que le c++ reste l'outils le plus adéquat pour des gros projet en jeu video, il ne faut pas en faire un dogme et rester ouvert à toutes les technologies.

En ce moment je suis en train de coder un petit jeu, je passe par un middleware avec du langage en Lua parce que je n'ai pas de grande ambitions si ce n'est faire un petit jeu rigolo en 3D pour mon plaisir personnel qui tournera correctement au demeurant. J'ai choisi l'outil qui correspondait à mes besoins, a mes ambitions et au fait que je travaille seul sur ce projet !

[Invité]

Moi en tout cas, je suis sceptique sur l'augmentation de la puissance des processeurs et le fait que l'on multiplie les noyaux n'est pas si évident à gérer, il faut des langages qui tirent bien partie de la concurrence.

De plus, pour le peu de comparaison que j'ai fait entre C++ (GL, GLU et GLUT) et Java (AWT+JOGL) en me servant d'OpenGL, même sans utiliser des shaders, je n'ai pas perçu de différence notable de performance.

Pour ce que ça intéresse, je commence à remplir la base de données du Java(tm) Game Tome donc vous allez commencer à voir des jeux sur la page principale.

[shenron666]

1) C++ serait plus rapide que Java: faux si le jeu met suffisamment en oeuvre les GPU (cf. exemple ci-dessus où même Ruby atteint les mêmes perfs que C++, grâce à un thin wrap C# autour de DX10).

si tu met en oeuvre le GPU c'est plus du java, là on parle du code java
si tu utilises le gpu avec java tu utilises le gpu avec c++
au final, la partie du programme codée soit en java, soit en c++, c'est elle qui nous concerne ici
sinon je vais te dire que glsl ou hlsl sont plus rapides que java
compare ce qui est comparable, à programme égal algorithme égal machine égale ect java sera plus lent ou utilisera plus de resources

[Emmanuel Deloget]

si tu met en oeuvre le GPU c'est plus du java, là on parle du code java
si tu utilises le gpu avec java tu utilises le gpu avec c++
au final, la partie du programme codée soit en java, soit en c++, c'est elle qui nous concerne ici
sinon je vais te dire que glsl ou hlsl sont plus rapides que java
compare ce qui est comparable, à programme égal algorithme égal machine égale ect java sera plus lent ou utilisera plus de resources

Dans un jeu vidéo, on utilise régulièrement le GPU. Alors autant prendre ça en compte lorsqu'on discute de la pertinence d'utiliser Java pour programmer un jeu

Et le principe reste vrai: si le jeu est GPU bound en java, alors il aura les mêmes perfs - qu'il soit fait en Java ou en C++. Que Java soit plus lent ou pas (bon nombre de jeux amateurs sont GPU bound; en fait, la plupart du temps, ceux qui sont CPU bound le sont pour de mauvaises raisons (très souvent à cause d'un manque de connaissance des GPU)).

[Invité]

Je tiens à dire, quitte à être totalement hors-sujet, qu'il s'agit là d'une très bonne idée. Si tu trouve des jeux qui ont un niveau technique avancé, n'hésite pas à les mettre en "featured game", ce qui permettra aux personnes qui comme moi pense que le combat Java vs. C++ vs. C# est inutile de pointer des personnes sur ta page

Essaie de lancer "Ufukta Dans". Il utilise JME. Il est très beau, les avions et les effets de lens flare sont impressionnants. Le Java(tm) Game Tome compte plus de 70 jeux pour le moment. Waterstorm utilise LWJGL, je te le conseille aussi. Cosmic Trip est pas mal. J'ai pas encore mis JEMU, un super émulateur utilisant LWJGL. Ben Librojo a fait quelques jeux avec un très bon gameplay même si les graphismes n'égalent pas un FarCry, je te conseille Futuristic Arenas, il utilise GL4J. C'est dingue, si ça continue, j'aurai dépassé la centaine de jeux avant la fin de la semaine prochaine.

si tu met en oeuvre le GPU c'est plus du java, là on parle du code java
si tu utilises le gpu avec java tu utilises le gpu avec c++
au final, la partie du programme codée soit en java, soit en c++, c'est elle qui nous concerne ici
sinon je vais te dire que glsl ou hlsl sont plus rapides que java
compare ce qui est comparable, à programme égal algorithme égal machine égale ect java sera plus lent ou utilisera plus de resources

Bon sang, arrêtez avec ça. On peut quand même aller plus vite en Java qu'en C++. Vous partez toujours du principe que Java est moins performant que C++ mais il a ses propres optimisations aussi, il peut s'en sortir parfois mieux que C++, je ne dis pas qu'il s'en sort mieux tout le temps.

Dans un jeu vidéo, on utilise régulièrement le GPU. Alors autant prendre ça en compte lorsqu'on discute de la pertinence d'utiliser Java pour programmer un jeu

Et le principe reste vrai: si le jeu est GPU bound en java, alors il aura les mêmes perfs - qu'il soit fait en Java ou en C++. Que Java soit plus lent ou pas (bon nombre de jeux amateurs sont GPU bound; en fait, la plupart du temps, ceux qui sont CPU bound le sont pour de mauvaises raisons (très souvent à cause d'un manque de connaissance des GPU)).

TUER est CPU bound ou GPU bound selon toi? J'ai remarqué que ses performances dépendent surtout de la vitesse de transfert et apparemment, c'est pour une très mauvaise raison qui n'a rien à voir avec Java :
je n'utilise pas encore mon système de subdivision de l'espace (il est pas fini), je passe un très gros VBO (si disponible sinon j'utilise les vertex arrays ou les display lists) à la carte 3D.

[TanEk]

Et si la solution était le C++ ET le java ? Le moteur 3D super optimisé de la mort qui tue en C++ et le développement du jeu en lui-même en java ?

[Ange_blond]

En ce qui me concerne au boulot, c'est moteur C++ basé sur OSG, et interface Java sous la forme de plugin eclispe...

Juste ceci pour dire qu'on peut presque tout faire en mixer à souhait...

[Invité]

Et si la solution était le C++ ET le java ? Le moteur 3D super optimisé de la mort qui tue en C++ et le développement du jeu en lui-même en java ?

Fausse bonne idée selon moi. Comme Java peut parfois aller plus vite que C++ et que Java est très portable, mieux vaut écrire un jeu entièrement en Java en cherchant à l'exploiter correctement pour que les performances soient au rendez-vous selon moi. Certains jeux utilisent un binding en Java pour un moteur en C++. C'est pas mal mais on perd un peu de performances en passant par JNI/JNA et parfois aussi un peu de portabilité. Et pourquoi on n'écrirait pas un "moteur 3D super optimisé de la mort qui tue en" Java? Certains industriels arrivent bien à mélanger de l'assembleur avec Java (pour répondre à ceux qui parlent d'optimisations bas niveau) donc où est le problème?

[shenron666]

Et si la solution était le C++ ET le java ? Le moteur 3D super optimisé de la mort qui tue en C++ et le développement du jeu en lui-même en java ?

c'est ce que fait "Call of Juarez"
tout ce qui est "critique" au niveau du moteur du jeu est écrit en c++ et assembleur
la partie scripting du moteur est écrite en java

en même temps écrire un jeu intégralement en c++ aujourd'hui ça ne se fait pas
il y a des bibliothèques comme lua pour faire du scripting ou de l'IA sans que la personne qui en aura la charge soit un programmeur
pour l'interface utilisateur également, on va pas la coder en c++, on a un moteur qui va gérer des scripts encore une fois et c'est une personne dédiée qui va s'occuper du design de la GUI
le c++ a un inconvénient majeur : il nécessite la compilation et le linkage du code
on va pas recompiler le moteur juste pour ajouter un bouton dans un menu

quand à utiliser java intégralement pour un moteur graphique ou physique je ne vois pas en quoi ce serait impossible non plus
je sais que gouessej ne sera pas d'accord avec moi mais cette orientation aura un impact de limitation sur les capacités du moteur

la topo est le même avec l'assembleur
si on codait aujourd'hui un moteur physique intégralement en assembleur plutot qu'en c++ ça prendrait du temps mais on y gagnerai en performances
la question est de savoir si le cout en temps de développement vaut le gain de performances apporté par le langage (en partant du principe qu'on a un programmeur qui sait ce qu'il fait et exploite le langage à fond)

[screetch]

Bon sang, arrêtez avec ça. On peut quand même aller plus vite en Java qu'en C++. Vous partez toujours du principe que Java est moins performant que C++ mais il a ses propres optimisations aussi, il peut s'en sortir parfois mieux que C++, je ne dis pas qu'il s'en sort mieux tout le temps.

le probleme c'est que si il ne s'en sort pas mieux, tu ne peux rien y faire (a moins de triturer ta VM). en C++ tu as la possibilité de réecrire des parties différemment, sans faire appel a une methode virtuelle pour gagner un peu, etc.

[Invité]

le probleme c'est que si il ne s'en sort pas mieux, tu ne peux rien y faire (a moins de triturer ta VM). en C++ tu as la possibilité de réecrire des parties différemment, sans faire appel a une methode virtuelle pour gagner un peu, etc.

Je ne vois pas où tu veux en venir. Java optimise déjà pas mal de choses sans te demander ton avis et laisse quand même de l'espace à ceux qui veulent aller plus loin. Sur les machines virtuelles actuelles, Java détecte si une méthode devrait être "final" alors qu'elle n'est pas déclarée ainsi dès le chargement des classes. Je mets quand même "final" quand je sais que c'est mieux mais si je ne le faisais pas, la JVM le ferait à ma place. J'ai peut-être tort mais j'ai surtout l'impression que certaines personnes ici connaissent mieux le C++ que Java et parfois parlent de Java à partir de ce qu'il pense être juste alors que c'est faux. Je ne vois pas en quoi Java ne permettrait pas de réécrire certaines choses différemment. Les méthodes Java sont par défaut "virtuelles" au sens de C++ sauf si la JVM les juge "final" au sens Java ou si l'utilisateur utilise le modifieur "final". Je précise mon propos:
On parle de RTTI (Run-Time Type Identification). Java détecte par défaut le type dynamiquement sauf si on lui précise le contraire (modifieur "final"), C++ détecte le type statiquement sauf si on lui précise le contraire (modifieur "virtual", mot-clé "dynamic_cast<>"). La méthode statique est moins coûteuse mais peut amener des problèmes difficiles à déceler alors que la méthode dynamique est plus coûteuse mais plus simple à appréhender en Java tout du moins selon moi.

Utiliser Java pour un moteur, ce n'est pas une limitation et je rappelle qu'il n'est nul besoin de parler de ça au mode conditionnel puisque même à l'époque où il n'y avait pas de binding d'OpenGL pour Java, des gens avaient déjà réussi à faire des jeux vidéo 3D en rendu logiciel. Je sais bien que le rendu logiciel n'est pas top niveau performance, je suis bien placé pour dire ça quand je compare T.U.E.R (8 à 400 FPS en fullscreen, OpenGL) et son ancètre Art Attack (0.5 à 37 FPS en fullscreen, software raycasting).

Je ne pense pas qu'un moteur entièrement codé en assembleur serait si performant que shenron666 le prétend car ce n'est pas en utilisant une approche forcément bas niveau qu'on a de meilleures performances. Parfois, on croit faire bien et on fait très mal en fait. Un enseignant m'avait parlé d'un de ses élèves qui avait écrit un petit jeu en assembleur. En fait, selon lui, les appels système qui étaient faits pour afficher chaque pixel étaient plus coûteux que si l'élève en question avaient utilisé SDL avec du C par exemple et qu'il avait compilé son programme... Il y a une petite marge d'optimisation quand on regarde le code en assembleur produit par un compilateur C/C++ ( gcc -S ). Encore une fois, c'est une erreur de privilégier les optimisations bas niveau, il faut faire les choses dans le bon sens, commencez par optimiser la conception de l'application, les algorithmes, leur implémentation dans un langage de haut niveau et enfin triturer ce que vous pouvez (en assembleur par exemple) si ça ne suffit pas.

[screetch]

combien de mega octets pour faire tourner la VM ? y a t'il des allocations "sur la piles" qui ne créent pas des allocations sur le tas ?
portabilité de java sur les consoles?

j'ai l'impression que toi meme, tu ne connais pas trop le C++.