Page précédente[Programmation] Priviligier les langages de Bas Niveau ou basic pour les jeux vidéo ?
| gouessej |
Posté le 21 Août 2008 à 10:02
|
|
 Messages : 337 GCPoints : 64624 |
Citation :
Chaque matin, je me réveille en me disant que ce que je fais est juste. Le garbage collector et le compilateur JIT de Java sont très mûrs, ils ont nécessité énormément de travaux de recherche et sont bien plus au point que ceux de C# (qui est plus jeune). Java est tout à fait adapté à la création de jeux vidéo, je voulais juste éviter de répéter ce que je dis déjà sur plusieurs forums. Citation :
Java peut éventuellement s'avérer plus rapide que C++, je ne dis pas que c'est tout le temps le cas. Regarde le benchmark de Jake2, ça montre bien que sur certaines machines, Java s'en sort mieux que C++ mais pas sur toutes. Citation :
Désolé mais ce n'est pas si simple que ça. Il est vrai que des librairies comme SFML, SDL, OpenGL, OpenAL... te facilitent bien la tâche mais moi j'ai eu des soucis quand j'ai voulu gérer l'auto-centrage du curseur, la fonction GLUT ne marchait pas sous Windows alors il fallait utiliser l'appel équivalent de l'API Win32. Je ne parle même pas de la gestion des signaux même en se contentant des méthodes POSIX  En tout cas, mon jeu s'installe sur 4 familles de système d'exploitation différentes en 2 clics au plus et sans que l'utilisateur ait besoin de savoir ce qu'est un système d'exploitation, cela ne m'empêchant pas d'utiliser OpenGL. Qui peut en dire autant sans se servir de Java? Autopackage n'est pas aussi portable que Java Webstart, de même que Bitrock Installer et IzPack. Ne me parlez pas d'écrire un installeur, je ne vais pas réinventer l'eau chaude et vraiment, s'il y a tant d'installeurs en place c'est qu'il y a un besoin de ce genre de programmes parce que ce n'est pas simple à faire. Citation :
Non ce n'est pas le cas mais moi au moins, je ne pénalise pas les utilisateurs de Mac et de Linux, ni même ceux sous OpenSolaris. J'aime bien Java mais cela ne m'a jamais empêché de critiquer Sun quand c'était nécessaire et aussi pour des raisons politiques. Citation :
Je suis en partie d'accord avec toi. Cependant, le JavaFX Preview SDK pre-release 1.0 n'est pas disponible pour Linux, il faut télécharger la version Mac et changer quelques variables d'environnement pour que ça marche. JavaFX utilise JMC, donc ça tire partie des modules natifs de chaque machine. D'un certain point de vue, ce n'est pas une solution satisfaisante même si ça va permettre de faire du playback assez aisément.
Dernière édition le 21 Août 2008 à 10:08
|
|
| SEB |
Posté le 21 Août 2008 à 10:13
|
|
 Messages : 554 GCPoints : 103313 |
Moi je suis assez pro java... (en tout cas je l'aime bien ^^) mais je me demandais.. l'interpréteur java... il est codé en quoi? ^^
NextGine : 3D games engine
Nombre de lignes actuel : 77683 |
|
| Mod |
Posté le 21 Août 2008 à 10:35
|
|
 Messages : 4954 GCPoints : 2100823 |
Dixit un livre sur le Java, l'interpréteur est "généralement" codé en C ou C++. Est-ce que cela veut dire que l'interpréteur officiel est codé en ce langage, bonne question. | |
| gouessej |
Posté le 21 Août 2008 à 14:36
|
|
|
Messages : 337 GCPoints : 64624 |
Je sais juste que Jikes est écrit en C++. Cependant, ne perdez pas de vue que le compilateur JIT joue un rôle important. | |
| akd |
Posté le 21 Août 2008 à 14:37
|
|
 Messages : 319 GCPoints : 75439 |
Citation :
Et je rajouterais que très certainement quand les benchs se trouvent être trop lentes sur telle ou telle fonction on passe à l'assembleur. (puisque tout le monde sait que le compilo rajoute du code inutile et donc fabrique du code plus lent que notre bon vieux ASM)  (Et là je commence à plaindre les petites marmottes faiseuses de JVM). Et c'est là que le pire arrive avec des différences de temps d'exécution entre les machines si jamais par malheur les circuits des processeurs d'une même famille sont cablés légèrement différemment entre les fondeurs. (hein? comment ça en C/C++ on a le même problème?) En plus, la seule raison qui fait qu'il est difficile de construire du code compatible windows/linux est justement le fait que Microsoft ne respecte pas la norme POSIX. Une fois qu'on connait les différences (y en a pas tant que ça...) on bon petit #ifdef #define règle le soucis de la compatibilité windows/linux. D'ailleurs pour la petite histoire. Le seul langage que je connaisse dont le compilateur est écrit dans le même langage que le langage lui-même est l'ADA. [EDIT] Le compilo JIT (just in time?) fait perdre de la performance par rapport au pseudocode déjà optimisé... donc c'est un mauvais exemple[/EDIT]
Dernière édition le 21 Août 2008 à 14:40
|
|
| Mod |
Posté le 29 Août 2008 à 11:00
|
|
|
Messages : 4954 GCPoints : 2100823 |
Pour donner en plein dans l'assembleur en ce moment, et après multiple et minutieuses recherches, de l'accord de plusieurs documents, il s'avère que les compilateurs émettent aujourd'hui un code quasiment aussi efficace que ce qu'un programmeur pourrait faire directement. Il était aussi mis en avant le fait que la différence des temps d'exécutions entre un code assembleur fait main et celui d'un compilateur était d'autant plus minime que la puissance des processeurs augmente, ce qui rend l'optimisation manuelle quasiment inutile, le gain en terme de calculs ou cycles CPU étant imperceptible. |
|
| gouessej |
Posté le 05 Sep 2008 à 10:27
|
|
|
Messages : 337 GCPoints : 64624 |
Citation :
Et si tu fais la moindre bêtise en programmant à la main, tu fais bien pire que de l'assembleur, il faut aussi le rappeler. L'assembleur n'est pas magique. |
|
Voir le profil
Envoyer un message privé
Voir le site
.