Discussion :

[Neckara]

Bonjour,

Je suis un fervent défenseur du C++ et depuis quelques temps déjà je travaillais sur un projet de jeu en C++.
Je voulais entre-autre :

• répartir tout le jeu dans un système de pluggin pour permettre à tous de "moder" ce jeu sans recompiler tout le projet ainsi que de pouvoir changer les dépendances (bibliothèques) si l'une d'entre elle n'était pas supportée sur une plateforme ou devenait obsolète ;
• permettre l'exécution du programme via navigateur (en jouant un peu avec les Websocket et un serveur en Node.js, le principe est assez simple).

Sauf que je rencontre pas mal de problèmes :

• le système de pluggin est relativement long à développer ;
• l'exécution via navigateur prendra aussi un certain temps et demandera soit que tous les calculs soient effectués côté serveur, soit de réécrire un client en JavaScript ;
• la non-portabilité des exécutables me dérange aussi quelque peu, je peux difficilement demander aux utilisateurs de compiler eux-même (s'il faut recompiler des dépendances, ou autre ça peut très vite devenir "enquiquinant").

Même si je ne porte pas vraiment le Java dans mon cœur, je suis très sérieusement en train de songer à cette possibilité, ceci :

• me fera gagner un peu de temps pour la partie "exécution via navigateur" grâce aux applets ;
• facilitera le système de pluggin (un pluggin sera alors un .class qu'on chargera dynamiquement ?) ;
• m'évitera quelques cheveux blancs quant à la portabilité de mon jeu ;
• permettra une exécution sur téléphones (?)

Mais je me pose quelques questions :

• niveau performances, est-ce qu'il pourra tenir correctement de la 3D ? En effet, il est très difficile de faire des scènes 3D "légères" et sur des prototypes en C++ que j'ai réalisé (affichage de 9*6 objets identiques), je pouvais avoir un nombre de FPS relativement faible. Java ayant des bibliothèques encapsulant openGL, je suppose que les performances sont relativement égales ? Mais j'entends dire que le Java serait 30% à 70% moins performants que des langages natifs par rapport à la 3D ;
• est-ce que l'exécution sur téléphone est réaliste par rapport aux performances des téléphones actuels ? Est-ce que vous pensez qu'il pourrait y avoir des adaptations à faire ? Si oui, lesquelles ?
• En revanche, j'ai entendu dire que le Garbage collector posait quelques problèmes de performances pour ce type d'application, est-ce qu'il y a moyen de pallier cela ?
• est-ce que le Java vous semble un bon choix pour ce cas là ?

Est-ce que vous auriez d'autres conseils à me donner ?

[joel.drigo]

Salut,

Je ne peux pas te répondre sur tous les points (en particulier sur la partie mobile où je n'y connais rien), mais à mon avis, oublie l'argument "applet" pour l'exécution côté navigateur, la technologie semblant virer à l'obsolescence, probablement à cause de nombreux problèmes de sécurité. Pour la partie plugin, regardes du côté OSGI : c'est, à mon avis, un excellent support pour la gestion de la modularité (notamment multi-plateforme).

Globalement, je verrasi bien une solution hybride java/osgi, C/C++ (via JNI, comme par exemple JOGL pour la 3D) + javascript pour l'exécution côté navigateur (via des bibliothèques style angular, par exemple, pour gagner du temps sur les dev).

[Neckara]

Merci pour vos réponses,

Pour la partie plugin, regardes du côté OSGI : c'est, à mon avis, un excellent support pour la gestion de la modularité (notamment multi-plateforme).

Ceci me semble très intéressant et m'évitera de devoir le coder moi-même.
Par contre je ne trouve pas vraiment de détails "buvables" quant à son fonctionnement

javascript pour l'exécution côté navigateur (via des bibliothèques style angular, par exemple, pour gagner du temps sur les dev).

Le problème c'est qu'il faudra réécrire une partie du code en JavaScript
Peut-être vaudrait-il mieux créer un client "léger" qui téléchargera les ressources qu'à partir du moment où il en aura besoin ?

[Iradrille]

Le problème c'est qu'il faudra réécrire une partie du code en JavaScript

Regarde du coté de emscripten, il est possible que tu n'ai pas grand chose à changer / refaire.
(Niveau performance ça à l'air correct, en particulier avec asm.js.)

[Neckara]

Regarde du coté de emscripten, il est possible que tu n'ai pas grand chose à changer / refaire.
(Niveau performance ça à l'air correct, en particulier avec asm.js.)

Je connais emscripten, mais :

• j'ai peur que cela ne pose des problèmes si j'utilise trop de bibliothèques
  
  • il faudra compiler les bibliothèque pour emscripten ;
  • avoir trop d'indirection risque de se voir au niveau des performances ;
  • certaines bibliothèques pourrait ne pas être compatibles avec emscripten (?)
  
  
• pour l'utilisation de la 3D, je ne sais pas si tous les navigateurs vont supporter la charge requise par emscripten.

[hwoarang]

Pour avoir un peu trempé dans ce genre de problématique, franchement, l’exécution sur navigateur, il n'y a pas de solution idéale. Comme déjà dit, les applets sont en train de devenir obsolètes. Si tu veux faire de la 3D, tu seras obligé de les signer. Et si tu ne le fait pas par un vrai certificat (payant), les utilisateurs devront mettre la sécurité java au minimum et elles risquent de ne plus fonctionner à tout moment (le message d'avertissement actuel prévient que les applets non signées par certificat reconnu seront bloquées ultérieurement).

Concernant le passage Java desktop <-> Android, c'est loin d’être aussi facile qu'on pourrait le croire. Le plus simple, selon moi, serait d'utiliser un moteur 3D qui est déjà compatible. Par exemple JMonkey qui est open source et gratuit. Il y a pas mal de videos qui trainent sur ce moteur qui montrent des exemples. Ca donne une idée des performances. Ceci dit, dans le monde du C++, des moteurs capables de générer du code ou des exécutables pour android existe peut être aussi...

Au sujet des performances, franchement, je ne suis pas sur qu'il y ait une si grosse différence. Quand on voit ce que font certains jeux, on se dit que ceux qui mettent à genoux une carte graphique en affichant 15 modeles 3D ne s'y prennent pas comme il faut. Meme s'il faut reconnaitre que c'est plus simple de dire que l'outil est mauvais plutot que de reconnaitre que l'architecture choisie ne convient pas

[Iradrille]

Hello,

Niveau performance, si tu es limité par le GPU tu ne devrais voir quasiment aucune différence. Chaque appel à une fonction native (OpenGL par exemple) aura un léger surcout qui devrait être négligeable par rapport au temps que prendra la fonction.
L'exception étant : si tu as de très nombreux (et court) appels à DrawPrimitives / DrawIndexedPrimitives, là tu sentira vraiment le surcout. Mais si c'est le cas, tu auras de toutes façons des performances faibles aussi en C++ : surement un problème de conception / optimisation.

Si tu es limité par le CPU, alors le passage à Java se fera sentir.

Pour la portabilité du code, tu peux fournir un exe Windows, et les sources. Un utilisateur de Linux à déjà probablement dû compiler lui-même de nombreux programmes et devrait savoir le faire.
Mais sur ce point... C'est vrai que le C++ c'est pas la joie.