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.
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).
![]()
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).
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 ?
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 !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.
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...
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.
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 !
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.
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)).
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.
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.
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.
Dernière modification par shenron666 ; 30/05/2008 à 16h02.
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 ?
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...
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?
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)
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.
Dernière modification par Invité ; 25/05/2008 à 12h15.
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++.
Dernière modification par loka ; 22/07/2008 à 19h32.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager