Pourquoi un projet amateur et conséquent en java ne serait pas pérenne? quelles sont les limitations du langage qui mènent à cette conclusion?
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
Pourquoi un projet amateur et conséquent en java ne serait pas pérenne? quelles sont les limitations du langage qui mènent à cette conclusion?
Je ne sais pas si tu as déjà essayé de coder des jeux plus gourmand en java, mais je peux te dire que au niveau perfs ça rame, et, au niveau des threads il y a pas mal de conflit entre ceux utilisé par les classes de l'api java et ceux utilisé par JOGL. :/
Rien à voir avec ce que tu as utilisé pour codé ton jeux, donc...
A quel niveau les perfs sont elles faibles?
de quels threads utilisés par l'api parles-tu? (sur le serveur, hors threads propres au jeu, je n'ai que ceux venant de lib externes qui tournent (fenêtrage/input(SWT), network(netty IO), pool connection DB(C3P0)).
Vu que mon jeu est à 80% en java / 20% c++ (et un poil de Ruby), je pense que c'est assez représentatif.
Salut,
tu utilises encore Ogre4j ? (Comme autrefois)
Moi, je ne voulais pas utiliser un moteur pré-existant car je ne sais pas si tu te souviens mais je n'y comprenais pas grand chose et je ne m'y retrouvais pas. :/
Surtout que en java, il y a encore moins de documentation sur les moteurs de jeux. :/ (En tout cas à l'époque il n'y en avait pas beaucoup)
Je suis donc passé à JOGL et à AWT, qui eux, utilisent tout deux des threads, j'ai eu un packets d'exceptions de type "tread concurrent exception" et les perfs étaient pas génial surtout pour le rendu 3D de terrain et de modèles 3D; à partir de là les performances commençaient à devenir faible.
Je suis ensuite passé au c++ et depuis je n'ai plus aucune problème pour afficher quoi que se soit.
Mais bon, bien évidement j'ai du refaire des composants de rendus (pour dessiner avec opengl) ainsi que des guis et un système de gestion d'événements similaire à java mais en c++, et sans threads car ça devenais trop galère sinon. :/
Je ne sais pas comment toi tu as fais pour t'y retrouvé avec Ogre4j mais bravo.
Pour info, j'utilise JOGL 2 et Newt (API de JOGL-2 qui remplace awt/swing pour les fenetres et les inputs clavier/souris/etc/...), et j'ai refais les widgets.
Je n'ai pas de soucis de mémoire ni de thread en ce qui me concerne.
Salut,
Non Ogre4j n'est plus maintenu, j'ai donc écrit ma propre lib dynamique d'interfaçage entre le code java et le moteur Ogre3D(idem pour Bullet physics et openAL d'ailleurs), je manipule donc directement le code natif, ça offre plus de contrôle.
Les librairies de fenêtrage (AWT, Swing, SWT) nécessitent de leur injecter les threads qui vont manipuler les ressources qu'elles gèrent, avec SWT, un petit exemple:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7public SwtWindowEngine() { super(); this.gameWindow.initialize(this.display.buildShell()); this.hideCursor(); this.display.execute(this.gameWindow::open); }les thread concurent exception sont dus à une utilisation différente de la librairie.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4void execute(final Runnable r) { this.display.syncExec(r); }
JOGL est juste un binding au dessus d'OpenGL, si il y a des problèmes de perfs à ce niveau, c'est surement(pas sûr mais presque) dû à une mauvaise utilisation d'openGL(ou des subtilités qu'induisent le binding, possible aussi), mais la JVM n'intervient que très peu à ce niveau là étant donné que le code sous jacent est natif.
Il serait intéressant de faire un bench entre un app simple qui tourne en openGL et sont pendant JOGL, si ça n'éxiste pas déjà.
En effet, je serai curieux de savoir.
A l'époque je n'avais que JOGL 1.x mais comme ça devenait compliqué avec les threads de SWT/AWT et ceux de JOGL (je n'avais pas de code natif) je ne savais absolument pas comment utiliser les threads à l'époque, je suis donc passé au c++ qui je trouve, est quand même plus simple.
Je me demande si depuis le temps ça a évolué. A l'époque je me souviens que JOGL ne pouvait s'utiliser que dans des composants AWT.
Dans tous les cas il faut une lib de fenêtrage pour contenir le contexte 3D, le rendu se faisant dans un canvas, mais que ce soit SWT ou AWT, le concept reste le même.
C'est pas Lineage (2?) qui était fait en JAVA ?
Sinon, je trouve plutôt cool de me faire traiter de troll et de bouffon par lolilol sur son loliblog.
Oui bah la lib de fenêtrage de java ne convenait pas avec JOGL. :/
Pourtant je ne faisais que d'afficher des ArrayList de sommets avec JOGL et AWT pour le fenêtrage.
Déjà là j'avais des threads concurrent exceptions sur les arraylist. :/ (D'une part avec le thread de gestion d'événements AWT et d'autre part avec le thread de rendu de JOGL)
Je suis un peu d'accord avec toi, bien qu'avec quelques nuances:Envoyé par Lolilolight
La plupart des langages ont leur propres défaut. Quand on utilise mal un langage, on se retrouve justement avec des problème de perf, pareil en c++, si on gère mal certains aspects, on se retrouvera avec des bugs et des lags. Le java est plutôt puissant quand on en fait une utilisation correct. Par exemple, minecraft est complètement codé en Java, et ne ram pas trop. En c++ c'est certain, il demanderait moins de ressource, mais aurait été plus compliqué à développer.
Dans le monde du jeu vidéo, on se retrouve toujours avec le même débat:
Priorisé la vitesse de développement, ou les performances.
Dans un projet amateur, la question de vitesse de dev ne se pose pas, car on a tout le temps devant nous, c'est pourquoi on préfère utilisé des outils plus complexes, et plus couteux en temps de dev, mais plus optimisé par la même occasion.
J'ai vu que tu critiquais aussi unity, je ne comprends pas trop pourquoi un moteur de jeu comme unity serait moins bien qu'un moteur de jeu c++ comme Ogre, ou irrlicht. Pourrais-tu éclaircir ce point? (je ne compte pas lancer un troll, j'ai utilisé les trois moteur, et j'ai trouvé celui de unity beaucoup plus user friendly, et plus simple de prise en main, que ça soit pour le déploiement ou le dev).
En tout cas, ça fait plaisir de te voir revenir avec de bons messages lolilolight, welcome back.
Personnellement c'est au niveau professionnel où je dispose de plus de temps et où je suis plus enclin à privilégier de la performance au détriment du temps de dev.
En amateur pour finir un jeu il vaut mieux aller directement au but ; sauf évidemment lorsque le but est de se perfectionner et non de finir le jeu.
Minecraft n'affiche que des cubes en même temps. (Le développeur n'avait probablement pas le temps et avait probablement des contraintes budgétaire, donc, il a tout misé sur le gameplay sans doute, et pas trop sur le reste, cependant je reste très dubitatif sur toutes les informations qu'on balance à propos de l'auteur du jeux, de ce qu'il gagne, etc...)La plupart des langages ont leur propres défaut. Quand on utilise mal un langage, on se retrouve justement avec des problème de perf, pareil en c++, si on gère mal certains aspects, on se retrouvera avec des bugs et des lags. Le java est plutôt puissant quand on en fait une utilisation correct. Par exemple, minecraft est complètement codé en Java, et ne ram pas trop. En c++ c'est certain, il demanderait moins de ressource, mais aurait été plus compliqué à développer.
Mais je serai curieux de savoir les perfs d'un jeux AAA moderne en java. (Si ubisoft a décidé de ne pas tout coder en C# qui est un langage similaire au java il y a sûrement des raisons de performances la derrière.)
Ça dépend du temps dont on dispose, moi j'ai beaucoup de temps et pas de contraintes budgétaires donc j'ai privilégié le c++ qui était plus compliqué mais plus performant, sinon, je ne me serai pas cassé le cul et j'aurai bien sûr opté pour un moteur comme Unity par exemple et j'aurai fais comme la plupart des gens, mettre des jeux sur steam.Dans le monde du jeu vidéo, on se retrouve toujours avec le même débat:
Priorisé la vitesse de développement, ou les performances.
Unity est beaucoup plus user friendly, car, son but est similaire aux EDI de type visual studio avec le système de windows form qui a été conçus pour la création rapide d'applications.J'ai vu que tu critiquais aussi unity, je ne comprends pas trop pourquoi un moteur de jeu comme unity serait moins bien qu'un moteur de jeu c++ comme Ogre, ou irrlicht. Pourrais-tu éclaircir ce point? (je ne compte pas lancer un troll, j'ai utilisé les trois moteur, et j'ai trouvé celui de unity beaucoup plus user friendly, et plus simple de prise en main, que ça soit pour le déploiement ou le dev).
La seule grosse différence est que unity est conçus pour créer des jeux tandis que visual studio l'est pour des applications.
Cependant, unity, tout comme VisualStudio n'est pas opensource, donc, si tu veux faire ta propre version du moteur (ou bien modifier l'éditeur) pour par exemple rajouter des fonctionnalités, des menus, etc..., ou pire, si tu rencontres un bug, tu risques d'être bloqué.
Je n'avais donc que 2 choix possibles si je ne voulais pas être freiné dans l'innovation :
-Créer mon propre moteur ainsi que mon propre éditeur.
-Modifier un moteur de jeux opensource existant.
Etant donné que des moteurs tels que Irrlicht et Ogre (eux au moins on peut les modifier contrairement à Unity ou encore visual studio) contiennent un tas de code sources avec pleins de fonctionnalités dont je n'ai pas besoin.
J'ai choisi la 1ère solution en essayant de trouver un design simple et agile afin d'intégrer les fonctionnalités dont j'ai besoin, mais uniquement celles dont j'ai besoin.
J'en ai également profité pour rendre le code opensource afin que tout le monde puisse en profité, et puis, que chacun puisse contribuer ce qui m'a permit de faire le design le plus agile possible, ils n'ont pas fait le boulot à ma place, mais ils m'ont suggérer quelques bons principe, le design à base de composant est un exemple parmi tant d'autres.
Mais bien sûr, je me suis aussi basé sur des librairies et des frameworks existants, des sites webs, des bouquins, etc...
Tu peux rajouter des script dans unity pour pouvoir modifier l'éditeur, ce afin d'avoir exactement ce que tu veux. En effet on ne peut pas modifier le moteur 3D de unity, mais on peut l'influencer en rajoutant divers composants qui viendront se greffer dessus.
Ensuite j'avoue que je ne comprends pas pourquoi refaire un moteur 3D alros qu'il en existe beaucoup, qui seront (désolé de dire ça) surement mieux implémenté que le tien, car des développeur plus expérimenté travaillent dessus depuis longtemps afin de l'améliorer.
Tu parles d'innovations, je vois pas ce qui pourrait être plus innovant que unity concernant la création de jeux vidéo, il rend vraiment le developpement de jeu vidéo plus abordable et simple que si l'on part uniquement de openGL ou Ogre (c'est mon avis).
Quelles fonctionnalité te manquait-il dans les moteur récent pour avoir besoin de refaire le tien?
Le fait qu'on ne puisse pas modifier le moteur en lui même me gêne et même si on peut modifier l'éditeur avec des scripts, cela me gêne quand même de ne pas pouvoir le faire avec mon langage favori. :/
Et puis modifier avec des scripts n'est pas plus simple que de modifier du code c++ de haut niveau, je pense entre autre au framework QT avec sont outil QTCreator que je préfère largement à Unity et VisualSudio.
C'est beaucoup plus simple de faire planté un script que de lui faire faire ce que tu veux, un code compilé lui, te dira directement ce qui ne vas pas lors de la phase de compilation.
Les macro sous excell c'est une vrai horreur, je modifiais quelque chose et paf, ça plantait! Il fallait à chaque fois arrêter la macro, modifier le code, en plus ça te générais du code automatiquement dont tu ne comprenais absolument pas la signification. :/ (Avec l'outil d'enregistrement de macro)
Parfois c'est carrément l'EDI qui plantait.
Il faut savoir que en informatique de gestion, les études que j'ai faîtes, on fait beaucoup d'UML, de structurogrammes, etc..., donc, je n'ai absolument aucun mal à concevoir un design tel que ceux implémenté dans Irrlicht, Ogre, SWING/AWT en java, QT, etc...
En plus mon objectif premier n'étant bien sûr pas de faire un jeux en 3D, je ne sais même pas si je pourrai aller jusque là un jour, coder un FPS simple en 3D oui, mais ça n'est pas mon but principal de faire un moteur 3D super puissant pour des gros jeux que de toute façon je ne serai pas capable de faire tout seul. :/
Et puis je voulais regrouper tout les modules (réseau, graphique, son, etc...) dans un seul moteur exactement comme le fait la librairie SFML plutôt que d'en utiliser plusieurs ce qui souvent mène à des bugs. :/
Mais de là à dire que Irrlicht et Ogre sont mieux implémenté que le mien, je ne suis pas d'accord, ils possèdes juste plus de fonctionnalités.
Mon but était principalement de faire un moteur utilisant un design à base de composants comme les frameworks tel que QT, Swing, etc..., tout en intégrant SFML, le système de scene node et de particule de Ogre, etc..., etc...
Je suis plutôt satisfait du résultat.
Mon but n'était donc pas de faire un moteur purement 3D, même si j'arrive aisément à générer des terrains 3D avec mais ça, c'est grâce au design du moteur.
Je préfère un design comme ça plutôt que d'avoir affaire aux problèmes qu'il y a eu avec blizzard qui, à dû utiliser un hack car le moteur n'étais pas fait pour faire du pathfinding en 3D iso.
Je comprends pas trop, tu compares Unity/Visual studio/Excell et Qt, pourant tout ces outils sont radicalement différents. Et surtout, ne servent pas à faire la même chose.
Tu parle des macro d'excell qui sont une vrai galère, mais en faisais-tu une bonne utilisation?
Pareil pour visual studio/Qt/Unity. Si on utilise ces outils pour faire ce qu'il ne sont pas apte à faire, forcément on va atteindre des limites. En revanche si on les utilise correctement, il y aura pas de soucis.
Concrètement, qu'est-ce qui te gène dans unity? Tu ne développe pas ce point pour expliquer ton choix de faire un moteur.
De plus tu considère que ton moteur sera bien, c'est normal c'est toi qui le fait, il correspond donc à tes envies, mais quid des envies des utilisateurs? Lorsqu'on fait un outil, c'est avant tout pour des utilisateurs (sauf dans le cadre d'un dev perso, pour tester ses connaissances ....).
Tu choisis d'utiliser SFML pour intégrer ton moteur dans un environnement de fenêtrage non? Ou utilises-tu SFML afin de faire le rendu de ton moteur? Si c'est le cas, je pense que tu auras forcément des soucis de performances non?
C'est là où je veux en venir, la plupart des moteur 3D utilisent leur propres moteur de rendu, afin d'optimiser les routines de base. En quoi ton moteur sera-t-il plus performant/User friendly que les autres?
PS: Ne te trompe pas dans ma démarche, je ne cherche pas à descendre ton projet, mais au contraire à faire en sorte que tu nous expliques pourquoi tu créé ton moteur, les choix qui t'ont poussé à le faire, ce qui sera différent dedans etc .... Afin de le mettre en valeur par rapport aux autres
Je l'ai fais pour apprendre et aussi pour d'autres besoins personnels et je n'utilise pas SFML pour le rendu, juste pour le fenêtrage car comme tu le dis si bien SFML n'est pas assez performant pour les rendus 3D.
Bon, assez parlé, pour moi les macros d'excell, visual studio et tout ce qui inclus des scripts, c'est la même chose, et de toute façon avec des scripts il faut quand même coder, t'a juste le côté user-friendly en plus. C'est pas le côté user-friendly qui me gêne, c'est le fait de ne pas pouvoir touché au moteur.
Quand tu es pros ou que t'a envie d'apprendre comme moi, unity n'est pas vraiment un bon choix. :/
Pour en revenir au sujet principal, j'ai revu mon moteur pour la génération de la lumière et des ombres, et j'ai trouvé une idée pour la 3D, car jusqu'à présent en 2D la caméra est toujours en vue de dessus, donc, si je générais les normals maps et companie avec la caméra ça passait.
Malheureusement en 3D non car, la caméra n'est pas en vue du dessus, il fallait donc que je fasse deux caméras : une caméra en vue du dessus qui filme la scène du dessus pour générer la normal map et la heightmap, pour cela, j'ai décidé de mettre la caméra à la position de la lumière ambiante en faisant une translation des entités du vecteur entre la position des deux caméras avant de tout dessiner sur la texture de rendu qui génère la normal map et la heightmap.
Bonsoir,
Je pensais qu'une lumière ambiante n'avait pas de position, je me trompe ?
Oui et non ^^. Tout dépend de quelle lumière ambiante on parle. Il en existe deux types:
La lumière multi-directionnel, qui ne possède pas de position, sa valeur est ajouté à tout les rendus de lumière.
La lumière directionnelle, qu'on utilise pour simuler le soleil. Elle possède une hauteur, et une direction. Elle permet de générer les ombres facilement et de manière cohérente dans un jeu
@lolilolight
Tu utilise une caméra pour générer la normal map et la heigh map? Normalement tu ne devrais pas avoir besoin de ça :/. La normal map et la heigh map devraient être généré à partir du shader et du matériel de ton objet non?
Puis ensuite calculer pour chaque point le rendu de lumière à faire?
CAr là, si je comprends bien, si on rajoute plusieurs spot lumineux, tu vas regénéré la normal map et heigh map pour chaque spot lumineux?
Ah, je comprends mieux le truc, merci Skeud !
Et il faut placer cette lumière "vachement loin" de la scène, pour que les rayons qui arrivent soient presque parallèles ?
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