Java pour jouer?

Oui!! Sinon, cet article n’aurait rien de surprenant franchement. Présentement pour mon travail j’explore le monde de Java et je suis tombé sur plusieurs articles qui font l’éloge des bonnes performances des machines virtuelles Java avec des données et des arguments à l’appuie.

Vous avez sûrement déjà entendu que les programmes sous Java sont lent à l’exécution puisque ce ne sont pas des programmes compilés en code machine, mais du code interprété par un autre programme. Cela a pour effet de ralentir l’exécution puisque c’est un programme qui roule un autre programme. C’était vrai dans ses débuts, mais les plate-formes ont évoluées depuis et pour certaines fonctionnalités, Java est meilleur que du code natif.

L’allocation de mémoire
Java possède un Garbage Collector qui s’occupe de ne pas laisser de la mémoire inutilisée et gaspiller ainsi de précieuses ressources, mais il fait aussi autres choses. Au lieu de passer son temps à demander des espaces mémoires au système, Java peut réutiliser la mémoire des objets inutilisés. Cela accélère l’allocation. Dans le même sens, au lieu de demander des petits blocs pour chaque objet individuel, Java peut demander des gros morceaux qui seront utilisés plus tard par plusieurs objets.

De plus, il y a certaines techniques avancées qui permettent d’optimiser l’allocation selon ce qui doit être fait. Normalement, c’est au programmeur de trouver lui-même la meilleure technique, alors que Java s’en occupe et change de méthode comme bon lui semble durant toute l’exécution du logiciel. C’est donc du travail en moins pour de meilleures performances.

L’optimisation dynamique (HotSpot)
Les compilateurs qui prennent les codes sources pour les transformer en code machine peuvent faire certaines optimisations comme changer des variables en constantes si elles ne sont pas modifiées ou encore mettre des fonctions directement à l’endroit qu’elles sont appelées plutôt que de faire un appel à cette fonction ce qui est plus lent. Le compilateur de Java ne fait pas exception, mais étant donné que la machine virtuelle va exécuter le code, elle peut aussi faire des optimisations dynamiques. Cela signifie que les bouts de code qui sont les plus sollicités durant l’exécution, et qui sont impossibles à connaître à l’avance sans exécuter le programme, peuvent être aussi optimisés. C’est donc un point de plus pour la rapidité des parties redondantes.

JIT (Just In Time)
La machine virtuelle peut faire pratiquement n’importe quoi avec le programme qui est en ByteCode. Cela va jusqu’à compiler le ByteCode en code natif avant de l’exécuter. Les bouts du programmes qui sont compilés en code natif s’exécutent alors à la même vitesse que des programmes fait en C++. Le seul hic est que le démarrage de l’application est plus lent étant donné cette compilation, mais si cela permet de pouvoir rouler le même code sur plusieurs architectures, cela en vaut la peine, surtout pour les jeux vidéos.

—————————————————

Maintenant que nous savons que Java peut potentiellement servir à faire des jeux, il faut maintenant savoir quelles facilitées sont offertes pour les programmeurs. Pour ce qui est du 3D, Java peut utiliser les fonctions d’OpenGL dans un composant AWT ou Swing (pour ceux qui ne savent pas, c’est ce qui permet d’utiliser des fenêtres, boutons, etc.) en passant par JOGL. De la même manière, il est possible d’utiliser JOAL pour accéder aux fonctionnalités sonores d’OpenAL.

En plus, il y a des moteurs d’affichage de scènes 3D qui existent déjà et qui sont gratuits. JME (Java Monkey Engine) en est un bon exemple en plus d’avoir un nom très prometteur.

En conclusion, Java est intéressant comme voie. Bien entendu, les jeux demandant des effets visuels réalistes auront un peu de difficultés, mais qui a dit que les graphiques faisaient un jeu? (Pas Nintendo :P)

Liens pour plus d’informations