Discussion :

[shenron666]

le coup des outils annexes à un moteur c'est le parfait exemple du mélange des langages
wpf étant parfaitement adapté pour la création rapide d'une interface utilisateur c'est clairement avantageux de l'utiliser précisément ici
surtout que les outils sont nécessaires avant que le moteur lui même ne soit terminé et plus vite ils sont créés plus vite on peut avoir d'autres personnes sur le projet (concepteurs, graphistes, modeleurs, animateurs, ...)

je vois bien 2 avantages de java pour un designer de niveau d'un jeu par exemple :
- contrairement au c#, java est portable, si on préfère l'utiliser sous linux pas de problème
- l'éditeur peut être déposé sur un intranet ou un site web pour être accessible de n'importe où; en même temps c'est plus facile de le mettre à jour pour tout le monde en même temps

pour dx10 et c#, en cherchant un peu j'ai trouvé cet article :
Utilisation de DirectX 10 au sein d'une application WPF
visiblement c'est en C# mais je n'ai pas vérifié en profondeur
ah oui, ne pas oublier également, dx10 est limité à vista
(au cas où certains essaieraient sous xp )

[Invité]

Tiens je l'avais pas vu ce thread.

Alors JAVA j'y ai passé 6mois à faire des tests et a écrire ma propre API avec.
Le langage est productif et eclipse de très bonne qualité, ceux qui diront le contraire ne se sont pas penché dessus.

Mais malgré tout le bien que l'on puisse voir dans JAVA, il n'est clairement pas fait pour le jeu. Sans rentrer dans des considérations de Perfs, les APIs sont inexistante. 5 mois sur JOGL pour en arriver à la conclusion que je perdais mon temps.

J'ai développé il y a 3ans maintenant un framework en C++ dans le style de SDL et sfml plus récent et vraiment il n'y a pas photo, facile d'optimiser avec le C++ et surtout TOUTES les librairies interessantes permettent d'utiliser le langage.

J'ai essayé Ruby, Python durant 3 mois et JAVA durant 6 mois mais je reviens toujours au C++.

Bon la ca fait un bon moment que j'explore C# et toutes ces lib WPF, WCF, WF, LINQ, ..., et vraiment encore une fois JAVA est à la rue. Si je trouvais JAVA pratique, C# est magnifique.

Maintenant je vais me pencher sur la conception d'un jeu avec afin de me faire une idée de ce langage dans ce domaine. Je vois que microsoft à pensé a tous avec XNA, encore plus depuis la version 3.0, mais je regrette vraiment de ne pas avoir accès à OpenGL ou DirectX, car si c'est pour retomber dans des APIs haut niveau difficilement customisable, je craint d'être déçu comme je l'ai été avec JAVA.

Désolé mais JOGL est loin d'être à jeter à la poubelle et en C#, tu peux utiliser Tao Framework qui a fagocité CSGL pour accéder à OpenGL :
www.taoframework.com

C'est carrément faux que Java n'est pas fait pour les jeux, il y a plein d'API pour faire des jeux en Java, j'en ai déjà cité pas mal, je ne vais pas me répéter, va jeter un coup d'oeil sur www.javagaming.org, elles touchent à la fois le son (JavaSound, JOAL, JOGG, JORBIS, binding FMOD), la gestion des pérophériques (JInput), l'imagerie (JOGL, LWJGL, JAI...), l'intelligence artificielle, le réseau (JGN) et la physique. Je fais du Java depuis 2002. Si Java n'était pas du tout fait pour les jeux, j'aurais lâché l'affaire depuis longtemps.

tu es fatigant. pas de support des consoles, 120% des ressources au lieu de 100, voila, tout est dit, le marché s'orientant fortement vers les consoles et Dx10, java ne fera pas partie des grands élus. j'ai dit plus haut que cependant 90% des projets pourraient l'utiliser, pour ces 90% c'est le nombre de docs assez faible et le nombre de libs moindre qu'en C++ qui emporte la decision.

Non tout n'est pas dit. J'ai déjà contesté ton pourcentage, 120% c'est un peu exagéré selon moi et il n'y a pas que DirectX10 sur terre mais si ça a la côte dans le monde des jeux vidéo commerciaux. Je ne te laisserai pas cantonner Java aux applications web. Java est présent sur 5.4 millards d'appareils au total, on ne va pas se priver du jeu vidéo.

Attention, JAI c'est pour faire du traitement d'images (en général non temps réel). Par rapport à l'API standard, ça apporte surtout des opérations de traitement d'images supplémentaire inutile dans les Jeux vidéo et ça apporte surtout des fonctionnalités de calcul distribué.

C'est pas tout à fait vrai, je me sers de JAI au boulot pour du temps réel, on ne m'a pas laissé le choix. Cette librairie n'est pas aussi portable que le Java de base, c'est gênant.

[millie]

Attention, JAI c'est pour faire du traitement d'images (en général non temps réel). Par rapport à l'API standard, ça apporte surtout des opérations de traitement d'images supplémentaire inutile dans les Jeux vidéo et ça apporte surtout des fonctionnalités de calcul distribué.

[shenron666]

la version du SDK en cours actuellement est de mars 2008
le sdk de juin 2007 contenait les exemple dx10 ?

apparemment il n'y a pas de dx10 managé de prévu
mais dx10 serait utilisable en c#
je suis pas fan de dx, préférant opengl, donc je suis pas trop au courant des détails

[Emmanuel Deloget]

la version du SDK en cours actuellement est de mars 2008
le sdk de juin 2007 contenait les exemple dx10 ?

apparemment il n'y a pas de dx10 managé de prévu
mais dx10 serait utilisable en c#
je suis pas fan de dx, préférant opengl, donc je suis pas trop au courant des détails

Il y a des wrappers DX10 pour les langages managés en cours d'écriture, mais aucun d'officiel. La plateforme de programmation de jeux vidéos en C# reste XNA depuis l'abandon de Managed DirectX par Microsoft. Cf MDX10 par exemple.

[screetch]

Non tout n'est pas dit. J'ai déjà contesté ton pourcentage, 120% c'est un peu exagéré selon moi

j'en ai eu marre et je suis repassé sur les tests que tu as montré au debut (le premierl ien des benchmarks), je suis repassé et je les ai optimisé. le resultat est que j'ai, pour chaque benchmark que j'ai fait (la flemme de les faire tous, quand meme), un programme C++ environ 2 fois plus rapide. il n'y a que pour l'appel aux methodes virtuelles; java est plus rapide sur ce point. mais si c'etait absolument un probleme ici dappeler des methodes virtuelles, en C++ je retirerai le dispatch virtuel pour qu'il soit fait une fois au lieu de dans la boucle.c'est un peu limite comme optimisation, mais ca revient a ce que je disais : on peut optimiser le C++ au dela de ce que sait faire le java. non pas a hauteur de 120% comme je l'ai dit mais plutot environ 200%. (et mes optimisations n'ont pas souvent été au dela de rajouter un "inline" quelque part.

[Invité]

j'en ai eu marre et je suis repassé sur les tests que tu as montré au debut (le premierl ien des benchmarks), je suis repassé et je les ai optimisé. le resultat est que j'ai, pour chaque benchmark que j'ai fait (la flemme de les faire tous, quand meme), un programme C++ environ 2 fois plus rapide. il n'y a que pour l'appel aux methodes virtuelles; java est plus rapide sur ce point. mais si c'etait absolument un probleme ici dappeler des methodes virtuelles, en C++ je retirerai le dispatch virtuel pour qu'il soit fait une fois au lieu de dans la boucle.c'est un peu limite comme optimisation, mais ca revient a ce que je disais : on peut optimiser le C++ au dela de ce que sait faire le java. non pas a hauteur de 120% comme je l'ai dit mais plutot environ 200%. (et mes optimisations n'ont pas souvent été au dela de rajouter un "inline" quelque part.

Laisse tomber, je n'y crois pas une seconde. Autant le gars en question dit n'être pas fort en C++, ça je peux le comprendre mais sur des exemples numériques style Fibonacci etc... Java s'en sort aussi bien que C++ alors garde ton 200% pour toi.

[screetch]

Laisse tomber, je n'y crois pas une seconde. Autant le gars en question dit n'être pas fort en C++, ça je peux le comprendre mais sur des exemples numériques style Fibonacci etc... Java s'en sort aussi bien que C++ alors garde ton 200% pour toi.

bien que la fonction fibonacci soit recursive, en placant le mot clé inline, le compilateur a reussi a inliner pour les petites valeurs de n genre jusqu'a 10. or, dans fibonacci implémenté comme ca, pour fibonacci 45 par exemple, fibonacci(1) est appelé 700 000 000 de fois ou un truc comme ca. en cour circuitant a partir de 10, tu evites donc d'appeler fib(9), 8 7 6 5 4 3 2 1 et donc tu evites environ 2 milliards d'appels recursifs.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
screetch@bender:~$ time java -server fibo 45
1836311903
 
real    0m13.640s
user    0m13.625s
sys     0m0.008s
screetch@bender:~$ time ./fibo 45
1836311903
 
real    0m6.888s
user    0m6.884s
sys     0m0.004s

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
// -*- mode: c++ -*-
// $Id: fibo.g++,v 1.3 2001/06/20 03:20:02 doug Exp $
// http://www.bagley.org/~doug/shootout/
 
#include <iostream>
#include <stdlib.h>
 
 
inline unsigned long fib(unsigned long n) {
    if (n < 2)
    	return(1);
    else
	    return(fib(n-2) + fib(n-1));
}
 
int main(int argc, char *argv[]) {
    int n = ((argc == 2) ? atoi(argv[1]) : 1);
 
    std::cout << fib(n) << std::endl;
    return(0);
}

[ash.ice.loky]

Un petit lien sympa :

http://zi.fi/shootout/

le dernier test est parlant en ce qui nous concerne.
ensuite on peut discuter de l'implémentation ou de la version de la LIB (idem, pourquoi GCC?).

bref, il n'empêche que JAVA doit faire des appels C pour utiliser openGL ce qui tue les perfs.

[Mat.M]

bien que la fonction fibonacci soit recursive, en placant le mot clé inline, le compilateur a reussi a inliner pour les petites valeurs de n genre jusqu'a 10.

Un petit lien sympa :
http://zi.fi/shootout/
le dernier test est parlant en ce qui nous concerne.
ensuite on peut discuter de l'implémentation ou de la version de la LIB (idem, pourquoi GCC?).
.

A croire que vous n'ayez jamais conduit un projet de jeu vidéo jusqu'au bout !
Un jeu vidéo c'est PAS un benchmark sur des suites de fibonacci ou des boucles imbriquées !
Un jeu vidéo, puisque c'est on parle bien de jeu vidéo ici et que c'est le titre de cette section du forum c'est des étapes bien plus complexes que des tests de performances sur des suites de Fibonacci.

Sur ce genre de test Java peut être aussi sinon plus rapide que C++ parce que le code exécuté peut être plus optimisé.
Sur un projet de jeu vidéo c'est radicalement différent, il faut gérer le réseau l'intelligence artificielle donner un comportement aux personnages etc sans compter les interactions matérielles...
Et sur un projet de jeu vidéo complet et fini reste à voir si Java tient vraiment la route...

[ash.ice.loky]

A croire que vous n'ayez jamais conduit un projet de jeu vidéo jusqu'au bout !
Un jeu vidéo c'est PAS un benchmark sur des suites de fibonacci ou des boucles imbriquées !
Un jeu vidéo, puisque c'est on parle bien de jeu vidéo ici et que c'est le titre de cette section du forum c'est des étapes bien plus complexes que des tests de performances sur des suites de Fibonacci.

Sur ce genre de test Java peut être aussi sinon plus rapide que C++ parce que le code exécuté peut être plus optimisé.
Sur un projet de jeu vidéo c'est radicalement différent, il faut gérer le réseau l'intelligence artificielle donner un comportement aux personnages etc sans compter les interactions matérielles...
Et sur un projet de jeu vidéo complet et fini reste à voir si Java tient vraiment la route...

Bon moi je veux bien Mat.M, alors explique moi si l'IA ce n'est pas une suite de calcul, si la trigo ou les matrice ce n'est pas une suite de calcul, si les appels a la carte graphique ce n'est pas une suite de calcul ... si les acces aux ressources ce n'est pas benchable ?

On peut parler de tout et de rien, tourner autour du pot, mais il arrive un moment ou il faut mesurer, et le bench que je donner reprend précisément ces critères, jusqu'aux appel OGL on l'on JOGL écraser à cause des appels via JNI qui bride les perfs.

Par contre je suis d'accord qu'un jeu c'est plus qu'un moteur 3D, et donc une suite de tools, d'éditeurs, de scripts, d'acces Database pour les ressources, ..., et de temps.

Sur ces points je reconnais l'avantage des langages tel que C# et JAVA qui donne une productivité accru par une lib standard bien plus fourni.

Mais le core de l'appli nécessite de la puissance et ca c'est un bench qui te le donne ou alors donne moi ta méthode miracle.

[Invité]

Un petit lien sympa :

http://zi.fi/shootout/

le dernier test est parlant en ce qui nous concerne.
ensuite on peut discuter de l'implémentation ou de la version de la LIB (idem, pourquoi GCC?).

bref, il n'empêche que JAVA doit faire des appels C pour utiliser openGL ce qui tue les perfs.

Je remets en question la partie sur OpenGL. Il est vrai que les appels à la JNI ont un coût mais pas du simple ou double par rapport à C++, là c'est carrément exagéré, j'en suis sûr à 100%. Déjà, l'auteur ne précise pas la version de JOGL qu'il a utilisé. Les versions pré JSR231 étaient moins performantes, l'API a pas mal changé au passage à JOGL 1.1.0. Je suis bien placé pour connaître l'éventuelle différence de performance puisque ma première tentative pour écrire un FPS était en C++ (OpenGL+GLUT), la seconde en Java (JOGL+AWT+...), j'avais donc quelque chose de comparable quand j'en suis arrivé à virer le raycasting et à afficher quelques murs dans un premier temps.

A croire que vous n'ayez jamais conduit un projet de jeu vidéo jusqu'au bout !
Un jeu vidéo c'est PAS un benchmark sur des suites de fibonacci ou des boucles imbriquées !
Un jeu vidéo, puisque c'est on parle bien de jeu vidéo ici et que c'est le titre de cette section du forum c'est des étapes bien plus complexes que des tests de performances sur des suites de Fibonacci.

Sur ce genre de test Java peut être aussi sinon plus rapide que C++ parce que le code exécuté peut être plus optimisé.
Sur un projet de jeu vidéo c'est radicalement différent, il faut gérer le réseau l'intelligence artificielle donner un comportement aux personnages etc sans compter les interactions matérielles...
Et sur un projet de jeu vidéo complet et fini reste à voir si Java tient vraiment la route...

Va jeter un coup d'oeil aux jeux commerciaux écrits avec LWJGL, ça te donnera une meilleure idée. Je suis désolé, je n'ai pas le droit de les mettre sur The Java(tm) Game Tome, ça aurait été plus simple pourtant.

[bafman]

Bon moi je veux bien Mat.M, alors explique moi si l'IA ce n'est pas une suite de calcul, si la trigo ou les matrice ce n'est pas une suite de calcul, si les appels a la carte graphique ce n'est pas une suite de calcul ... si les accès aux ressources ce n'est pas benchable ?

certes, mais il y a une large différence entre exécuter des calculs en boucle et les utiliser effectivement dans leurs contexte final. Notamment au niveau de la gestion du cache processeur qui se fait literallement massacré par Java (plus d'indirect ion, pas d'objets dans la pile, obligé de stocker des info de GC à des emplacement totalement différents du tas...)

sinon, pour le coup de JOGL plus lent que openGL en C, je remet en doute l'utilité de ce bench, car l'objectif d'un bon moteur 3D étant de limiter autant que possible les batch et les appels à l'API, tout ce que montre ce bench, c'est que JOGL sera plus lent sur un moteur codé avec les pied... bref, pas très représentatif

[luckyvae]

Autre chose pour d'éventuels test de comparaisons: qu'est ce que l'on veut? le temps d'exécution du code ou le temps d'exécution du programme?

Parce qu'en java, il faut au départ que la JVM se lance, mais ça ne se produit qu'une fois, donc est-ce pertinent de le prendre avec?




P.S: et quand on parle d'optimisation et de fibonacci, siouplé, ne prenez pas la version naïve, prenez au moins une forme qui soit linéaire au nombre entré, ou alors prenez directement la bonne vieille formule

[HanLee]

Juste une question, vous y croyez vraiment quand vous dites que le GC bloque le jeu de manière inacceptable (dans le cadre d'un jeu) ?

Parce que, dans tous les jeux récents, quelle que soit votre configuration, vous avez des mini-blocages pour des mini-chargement de rien du tout, alors que ce soit blocage du au GC où non, perso j'en ai rien à faire.

Surtout qu'un GC très performant (celui d'OCaml par exemple) alloue la mémoire très vite, et la rend de manière imperceptible...

Je vais essayer de convertir mon petit moteur maison de particules fait en C++ en OCaml pour voir déjà si ça s'avère gênant dans ces cas-là (plein de particules -> plein d'allocation mémoire).

A priori, je trouve que c'est un argument vraiment peu convaincant, mais c'est pour ça que j'vais faire des tests.

[Invité]

Juste une question, vous y croyez vraiment quand vous dites que le GC bloque le jeu de manière inacceptable (dans le cadre d'un jeu) ?

Parce que, dans tous les jeux récents, quelle que soit votre configuration, vous avez des mini-blocages pour des mini-chargement de rien du tout, alors que ce soit blocage du au GC où non, perso j'en ai rien à faire.

Surtout qu'un GC très performant (celui d'OCaml par exemple) alloue la mémoire très vite, et la rend de manière imperceptible...

Je vais essayer de convertir mon petit moteur maison de particules fait en C++ en OCaml pour voir déjà si ça s'avère gênant dans ces cas-là (plein de particules -> plein d'allocation mémoire).

A priori, je trouve que c'est un argument vraiment peu convaincant, mais c'est pour ça que j'vais faire des tests.

Je suis d'accord avec toi sur le fait que c'est bidon cette histoire de blocage. Bon sang je n'ai JAMAIS observé ce genre de choses dans des jeux en Java alors que j'en ai testé plus d'une centaine! C'est du flan, ça ne tient pas la route une seule seconde! Même sur des jeux en 3D assez poussés je n'ai pas observé ça. De plus, j'ai précisé que vraiment dans les cas extrêmes, on peut choisir un algorithme de garbage collection plus adapté avec le "concurrent low pause GC" si j'ai bonne mémoire. Je le répète, certains arguments qui ont été avancés ici relèvent du pur préjugé et ne tiennent aucunement la route dans la réalité.

Quant à OCaml, je ne sais pas comment est implémenté le garbage collector, je pense que Java et OCaml sont deux langages très très différents, pas seulement au niveau de la syntaxe donc il ne faut pas tout mélanger. A te lire, on a l'impression qu'OCaml ne dispose que d'un seul algorithme de garbage collection, c'est déjà une grosse différence avec Java qui non seulement en dispose de plusieurs mais permet de les paramétrer assez finement. Par contre, il est vrai qu'OCaml et Java s'en sortent assez bien avec l'allocation et la désallocation mémoire.

Enfin, si tu veux vérifier que tu as bien raison, je t'invite à aller sur un site que j'ai créé avec 2 autres personnes regroupant plus de 100 jeux en Java. Aucun ne souffre du symptome dont ils parlent (ou alors j'envoie un petit email à l'auteur, je lui demande de retirer les appels Thread.sleep(...) inutiles, les forçages de finalisation d'objets, quelques petits trucs tout bêtes qui restent sous contrôle du programmeur) :
www.javagametome.com


Voilà c'est dit.

[DzzDDzzD]

ici un exemple plus "polished" :

http://www.jmonkeyengine.com/screenshots.php

http://www.jmonkeyengine.com/movies_demos.php

[supersnail]

Outre la simplicité de java par rapport C++,java est portable...
Si on crée un jeu en Java (tant qu'on utilise pas DirectX),on peut y jouer sous Windows,Linux,Mac.... tant qu'on a une JVM installée...
Mais en C++ on est obligé de compiler le même prog pour chacune des plateformes (donc plusieurs machines(et obligation d'acheter les OS (sauf Linux)si on passe par une solution virtuelle come VMWare ou VirtualBox) donc pertes d'argent...)

[DzzDDzzD]

pettite remarque supplémentaire :

dire que C++ ou java est plus rapide est un non-sens.

de nos jours les deux language sont compilés et terminent tous les deux par des instructons assembleurs/code machine, directement executés, la différence c'est que l'un est compilé avant distribution et l'autre est compilé à l'execution, un peu comme si on distribué les programmes en C sous forme de code source et qu'ils soient compilés à l'execution.

petit bemol quand meme sur java, deux points restent genants :

1 - l'acces aux tableaux est securisé (bounds check)
avantages:
on plante pas la machine en ecrivant ou lisant n'importe ou dans la memoire
inconveniant :
ben l'acces aux tableaux est ralentit par quelques op supplémentaire (CMP/JNE) pas tres lourdes mais suffisante pour rendre l'acces plus lent quand on y accede pas sequentiellement.

2 - l'acces via JNI est lent est provoque une chutte de perf si on le sait pas et qu'on fait 50 appels la ou on pourrait n'en faire qu'un seul avec plus de parametres.

à par ca comparait une boucle for()/while() etc.. entre java et c/c++ ou bien une expression mathematique n'a pas vraiment de sens, je pense qe le code assembleur produit derriere est peu different, et dans ce cas la ce n'est pas le language qui est en cause mais le compilateur (le JIT dans le cas de java)

donc suivant le JRE (version 1.1/1.6 et le fournisseur MS/SUN/IBM et bien d'autre) et le compilateur C/C++ utilisé (est la aussi la liste est longue) ben les bench donneront des resultats differents.

[DzzDDzzD]

juste un FPS sympa fait en java que j'ai oublié de donner :

http://nightsquad2.freenet.de/?lan=en

excellent