l'openGL c'est plûtot pour la 3D et un peu usine à gaz pour la 2D...
Sinon,la SDL je ne sais pas ce qu'elle vaut mais les APIs graphiques de java par défaut sont déjà pas mal... (de plus on peut lire des sons au format WAV et MIDI avec JavaSound)
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
l'openGL c'est plûtot pour la 3D et un peu usine à gaz pour la 2D...
Sinon,la SDL je ne sais pas ce qu'elle vaut mais les APIs graphiques de java par défaut sont déjà pas mal... (de plus on peut lire des sons au format WAV et MIDI avec JavaSound)
pour la 2D en java, tu as slick qui fait pas mal parler http://slick.cokeandcode.com/
une librairie 2D basée sur LWJGL (donc openGL).
perso, j'ai pas le niveau pour juger
Juste au passage, léger hors sujet, je suis en train de réadapter mon moteur de jeu du C++ (glut/OGL) vers C#/XNA
Je suis bluffé par la qualité de l'API
la seule différence entre 2D et 3D avec opengl c'est qu'une coordonnée ne seriva pas et restera donc fixeEnvoyé par supersnail
en dehors de cette différence, opengl n'est pas plus usine à gaz en 2D qu'en 3D
sinon avis à tous ceux qui veulent se mettre au mmog (rpg ou autre) commençez par faire un jeu simple (rpg ?) et lorsque le projet sera terminéon en reparle (ou pas...)
Ne le prends pas mal mais c'est hors sujet. Justement, c'est un débat. Toi, tu ne veux pas débattre, tu veux juste obtenir de l'aide pour ton projet, il y a des rubriques plus adaptées pour ça, par exemple la rubrique "Projets" :
http://www.developpez.net/forums/f14...-jeux/projets/
Si tu maîtrises la langue de Shakespeare, je te conseille de te rendre aussi sur le forum javagaming, tu y trouveras pas mal de gens très calés en programmation de jeux vidéo en Java.
Non, je rejoins Shenron à ce sujet. Il n'y a pas de fonctions OpenGL spécifiques à la 2D à ma connaissance. Par contre, dans la GLU, il y a gluOrtho2D mais tu peux faire la même chose avec glOrtho (avec near à -1 et far à 1).
SDLJava est un simple binding de SDL. Il est vrai que Java2D, AWT et Swing peuvent suffire, ça dépend de la complexité de la géométrie à afficher. Il me semble que JavaSound supporte un peu plus de formats que ça maintenant (il supporte aussi le format AU et AIFF), à vérifier. En tout cas, tu peux rajouter des SPI pour supporter d'autres formats, les MP3 et les OGG par exemple.
Quelqu'un a parlé de Slick, c'est bien maintenu. Il y a aussi FengGUI qui peut fonctionner avec JOGL ou LWJGL au choix mais c'est uniquement pour faire une interface graphique avec des composants relativement basiques.
Stagstrat, regarde aussi sur sourceforge, d'autres gens ont programmé des RPG 2D open source, ça peut t'inspirer. Il me semble que j'en mentionne au moins un sur mon portail de jeux Java.
Dernière modification par Invité ; 12/11/2008 à 10h12.
Pour moi, D est bien mieux paré que Java pour le domaine des JV en 3D temps réel, ne serait-ce que parce qu'on peut court-circuiter le GC et gérer à la main l'alloc mémoire ou faire de l'inline asm (SIMD ?). Mais à part le compilo basé sur le back-end GCC, je ne pense pas que les jeux soient portables sur consoles, ce qui est un gros inconvénient pour un studio.
Au passage, à titre indicatif, Gears of War a été développé en C++ + scripts (je ne sais pas quel langage, p-ê Lua) 250 KLOC, avec des librairies comme OpenAL/SDL sur l'Unreal engine (250 KLOC à lui tout seul, OpenGL). L'architecte de ce dernier plaide pour le remplacement de C++ par un langage plus proche des langages fonctionnels pour pouvoir exploiter les processeurs multicores, quitte à avoir un langage de prog 10% moins performant mais plus facile à utiliser.
pour info, c'est 250KLOC pour le jeu, et 250 KLOC pour le moteur unreal engine, le tout etant un mélange de C++ et unreal script pour le jeu et principalement du C++ pour le moteur.
tout est ici :
http://www.st.cs.uni-saarland.de/edu...ocs/sweeny.pdf
Court-circuiter le ramasse-miettes afin de gérer la mémoire à la main ne permet pas nécessairement d'avoir de meilleures performances. Je rappelle que toute désallocation mémoire au sens propre du terme directement sur le système d'exploitation a un coût système non négligeable et qu'une des forces de Java est justement que c'est la machine virtuelle qui gère son propre tas; ainsi, les désallocations mémoire sont jusqu'à 4 fois plus rapides que dans des langages sans ramasse-miettes et la JVM tente de les faire au moment où c'est le plus opportun (mais pas toujours, toute oeuvre humaine est perfectible). Par conséquent, court-circuiter le ramasse-miettes peut te permettre dans de rares cas de faire mieux et le plus souvent c'est pire. J'ai déjà mentionné dans cette discussion qu'il existe des moyens en Java de faire de la désallocation explicite. Le ramasse-miettes est le fruit de nombreux travaux de recherche durant maintenant plus d'une dizaine d'années. Il faut peser ses mots quand on parle de faire mieux qu'elle selon moi.
Par contre, dans des langages où il est moins mûr qu'en Java, la gestion de la mémoire à la main peut peut-être permettre d'améliorer les performances mémoire de façon plus sensible.
Je ne vais pas revenir sur l'inlining, Java en fait déjà depuis des lustres, le JIT fait bien son boulot. Quant à SIMD, on en a déjà parlé, c'est utile mais ce n'est pas non plus la panacée. Il semblerait que dans un avenir incertain, Java tire enfin partie de SSE. Une JSR dans ce sens a été rejetée car elle proposait une API pour faire ça un peu à la main alors que Sun envisage (mais pas dans Java 1.7) de déléguer ce genre d'optimisation à la machine virtuelle et plus précisément au compilateur JIT. Des benchmarks intéressants à ce sujet sont sur Javagaming.org.
Edit : Le langage D est un peu plus jeune que le langage Java, il a été créé en 1999 et est essentiellement soutenu par la société Digital Mars. La version 1.0 date de début 2007. Je pense qu'il est trop tôt pour se prononcer sur son avenir dans les jeux vidéo.
Dernière modification par Invité ; 17/12/2008 à 16h13.
Pour recentrer le débat, il y a encore un jeu Java commercial en plus, la suite de "Commander: Europe at War" qui se nomme "Commander: Napoleon at War".
pour 50 jeux en C/C++ sort un jeu en java...
Bien que la GC demande moins de ressources a la désalloc, il ne fait pas mieux que des pools C++.
De plus, il demande un suivis détaillé des références et un analyse de graph.
Pas que je sois contre le garbage collector, qui se justifie selon moi dans 90% des cas, mais dans les section de code critique, il vaut mieux pouvori le désactiver.
Comment ces personnes qui font des jeux gèrent le temps en java ? Jamais trouvé de moyens efficaces.
Je rappelle que le débat n'est pas savoir si le C/C++ est mieux adapté pour les jeux vidéo que le Java. Ceci est un autre débat
L'argument n'est pas pour comparer C++ et Java mais pour montrer que les jeux java représentent une infime minorité et que très peu de gens s'y risquent.
Supposons que tu aies raison, ce n'est pas vérifiable comme le plus souvent ceux qui écrivent des jeux vidéo commerciaux en Java ont plutôt tendance à ne pas mentionner ce "détail" et à faire le nécessaire au niveau du packaging pour que l'utilisateur final ne voit pas la différence.
Le ramasse-miettes ne se limite pas à un simple pool, loin de là.
Je ne vois pas du tout ce que tu veux dire. Vu le nombre de jeux vidéo commerciaux et non commerciaux écrits en Java et de tout genre, cela n'a pas l'air de poser un problème. En Java, il existe des méthodes permettant de mesurer avec différentes précisions (en nanosecondes et en millisecondes) le temps qui s'écoule, le timer le plus précis étant celui utilisé dans JMF dans les classes implémentant l'interface javax.media.Clock. On peut quand même arriver à s'en sortir avec les méthodes de l'API standard et c'est amplement suffisant.
Pourtant, beaucoup ici évoquent quasi systématiquement C++ et il faut faire la distinction entre les jeux Java en général et les jeux Java commerciaux. Il existe de très nombreux jeux non commerciaux écrits en Java, le plus souvent sous forme d'applets ou d'applications installables via Java Webstart, IzPack (plus rarement) ou sous forme de packages (RPM, DEB) créés avec Ant et/ou JPackage. De plus, les programmeurs de ce genre de jeux ne sont pas toujours très doués pour faire connaître leurs oeuvres, c'est pour cette raison qu'il m'a été difficile de tenter de recenser tous les jeux Java. Il y en a vraiment des centaines. Le plus souvent, un peu comme les créateurs de jeux sous RPGMaker, seul le milieu métier connaît ces jeux, c'est dommage.
Pour les jeux commerciaux, c'est autre chose comme certains utilisent des méthodes de packaging qui dissimulent complètement le fait que l'oeuvre soit écrite en Java, par exemple en utilisant une machine virtuelle privée couplée à LWJGL ou bien en compilant le code source Java directement en code machine.
Dernière modification par Invité ; 18/12/2008 à 10h10.
et pourquoi il ferais cela
Parce que l'utilisateur final se moque de savoir ce qu'il y a derrière, il veut juste installer son jeu, il faut que ce soit le plus habituel possible, il faut qu'il installe son jeu écrit en Java de la même façon qu'il installerait n'importe quel autre jeu écrit dans un autre langage.
et pourquoi il ferais cela
En fait, je remarque que les utilisateurs n'aiment pas qu'on change leurs habitudes surtout s'ils ne comprennent pas pourquoi on fait ça, s'ils n'y voient aucun gain. Il n'y a qu'à voir les réactions des gens qui installent un jeu Java via Java Webstart pour la première fois. Certains me disent "l'installation est un peu bizarre". Vous savez aussi que Java a encore mauvaise presse auprès d'une partie du public
Dernière modification par Invité ; 18/12/2008 à 10h13.
En même temps, quand j'achète un jeu développé en C++, c'est pas écrit non plus
et pourquoi il ferais cela
oui bien sure, l'utilisateur s'en fou un peu au final.
Mais c'est juste que sa phrase me fait bizarre. C'est comme s'il voulais dire que plein de jeux sont fait en java mais que c'est caché pour raison de markéting.
c'est peu être le rhume qui me monte à la tête
Exactement.
Oui c'est caché pour des raisons de marketing mais encore une fois, quand tu dis plein de jeux, j'ai l'impression que tu parles des jeux commerciaux comme juste avant, on parlait des utilisateurs qui achètent des jeux, c'est bien ça? Je sais qu'il y a plein de jeux vidéo non commerciaux écrits en Java.Mais c'est juste que sa phrase me fait bizarre. C'est comme s'il voulais dire que plein de jeux sont fait en java mais que c'est caché pour raison de markéting.
c'est peu être le rhume qui me monte à la tête
Par contre, pour les jeux vidéo commerciaux écrits en Java, je n'ai jamais dit qu'il y en a plein ("plein" c'est vague), il y en a, ça c'est sûr comme certains (pas tous malheureusement) ne cachent pas qu'ils se servent de Java mais je ne suis pas en mesure de savoir exactement combien justement car il est possible que les éditeurs fassent comme pour "Commander: Europe at War" c'est-à-dire ne mentionner Java ni sur l'emballage ni pendant l'installation ni pendant l'exécution. Il faut aussi prendre en compte les jeux commerciaux qui se jouent uniquement via internet.
Au final, je suppose qu'il y a au moins plus d'une dizaine de jeux vidéo commerciaux écrits en Java sur PC dont les puppy games (Droïd Assault, Ultratron, Tribal Trouble, Gravitron 2), Commander: Europe at War, Commander: Napoleon at War, Runescape (l'upgrade du compte coûte 5.95 USD), Shadowbane (version d'essai de 15 jours gratuite), Puzzle Pirates. Je précise que je ne compte pas tous les jeux vidéo commerciaux écrits en Java pour téléphones mobiles. Plus d'une dizaine, c'est peu mais il faut bien commencer par quelque chose, ça ne veut pas dire qu'il faille enterrer Java pour les jeux vidéo commerciaux sur PC et d'ailleurs, j'ai déjà dit que la société Funcom travaille sur deux jeux pour PC écrits en Java qui devraient sortir courant 2009.
Edit : Je m'attends à des comparaisons avec d'autres langages mais je rappelle qu'à une époque lointaine, les jeux étaient essentiellement écrits en assembleur.
Il me semble que la série des Football Manager est aussi en Java, enfin c'est à vérifier.
Houlà, faut remonter à Pong pour ça, non? Ou alors tu veux parler de certains jeux où, grosso-modo, 1% du code est écrit en assembleur (les parties les plus critiques question perfs)
Code : Sélectionner tout - Visualiser dans une fenêtre à part à une époque lointaine, les jeux étaient essentiellement écrits en assembleur.
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.
Répondre avec citation
Partager