TUER : FPS EN JAVA+JOGL+JOGG+JORBIS
Twinuts
Messages postés
5375
Date d'inscription
dimanche 4 mai 2003
Statut
Modérateur
Dernière intervention
14 juin 2023
-
1 sept. 2007 à 13:45
Utilisateur anonyme - 23 nov. 2010 à 23:36
Utilisateur anonyme - 23 nov. 2010 à 23:36
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/43941-tuer-fps-en-java-jogl-jogg-jorbis
https://codes-sources.commentcamarche.net/source/43941-tuer-fps-en-java-jogl-jogg-jorbis
23 nov. 2010 à 23:36
Je donne quelques nouvelles de mon jeu ici :
http://gouessej.wordpress.com/2010/11/23/tuer-4-ans-deja/
11 mai 2010 à 13:42
11 mai 2010 à 09:38
tu fais honneur aux roux mec.
9 mars 2010 à 19:12
Premièrement, JMonkeyEngine n'est utilisé que dans une des versions qui est abandonné, il est donc fort probable que tu n'en aies pas besoin. Deuxièmement, si tu utilises cette version, il faudra que je t'envoie un patch car j'ai corrigé pas mal de bogues dans JME 2.0 et mes correctifs n'ont pas été intégrés.
Troisièmement, le fichier "build.xml" est ici :
http://code.google.com/p/jmonkeyengine/source/browse/#svn/trunk
Enfin, je te recommande d'utiliser soit la version alpha qui est la plus complète et qui subit uniquement des vagues de maintenance (elle n'utilise aucun moteur externe, elle est assez facile à installer) soit la version pré-bêta qui est moins complète et encore en cours de développement (elle utilise Ardor3D qui est assez simple à installer).
9 mars 2010 à 18:23
j'essaye d'installer le jeu sur eclipse....je suit les étapes indiqués sur le site http://tuer.sourceforge.net/download.php..
et je trouve pas en fait le fichier :"build.xml" pour installer le JMonkeyEngine sachant que j'ai téléchargé le jME2_0_1-Stable à partir du lien indiqué sur le site
14 sept. 2009 à 22:32
Merci du compliment. Par contre, il faut que je mette les liens à jour, j'ai dû tout déplacer sur Sourceforge comme Tuxfamily prend l'eau :(
http://tuer.sourceforge.net
14 sept. 2009 à 19:02
16 févr. 2009 à 20:05
Mon projet continue. Je pense mettre à jour le code source sous peu mais je voudrais terminer l'intégration de mon scénographe à l'intérieur de JMonkeyEngine 2.0.
30 sept. 2008 à 13:12
Le code source a beaucoup changé. Si vous voulez suivre le projet, je vous conseille d'utiliser le dépôt SVN de sourceforge pour ce projet. Je soumettrai une mise à jour ici dès que possible. Au menu :
- le scénographe est déjà en majeure partie opérationnelle, le frame rate est meilleur sur les petites configurations
- les applications audio ne font plus planter le jeu
- TUER marche sur ATI XPress 200 sous Windows (21 FPS avec les derniers pilotes) et sous Linux (2 FPS, le bug d'initalisation mémoire du pilote n'a pas été corrigé)
Je voudrais corriger quelques problèmes importants avant de poster quoi que ce soit ici.
9 juin 2008 à 21:06
Le code source a été mis à jour. Au menu :
- un kit médical permet de reprendre des forces
- le jeu fonctionne de nouveau à peu près bien sur les chipsets VIA et SiS
- la gestion des déplacements du regard avec la souris est plus fluide et beaucoup plus précise
- le bogue des explosions suicidaires a été corrigé
- d'autres bogues mineurs et vices de conception ont été corrigés, notamment au niveau de la conception MVC
31 mai 2008 à 22:59
Le jeu va bientôt passer à JOGL 1.1.1 quand un petit souci avec les TextRenderers sera règlé. Les cartes graphiques sous OpenGL 1.2 et 1.3 vont de nouveau être supportées par le moteur, c'était juste un problème de taille de textures.
26 avril 2008 à 02:01
Le jeu n'utilise pas DirectX mais OpenGL, juste à titre indicatif. C'est curieux, le problème avec la souris semblait réglé, c'est quand même beaucoup plus précis qu'avant. Je suis surpris aussi car sur une machine équivalente à la tienne avec une NVIDIA FX 5200, le jeu est monté à 52 FPS. Qu'est ce que c'est L2J??
A bientôt.
25 avril 2008 à 14:59
Je précise, tout de même, que le jeu à été lancer sous WindowsXP EF SP2, Nvidia GE ForceFX 5600 (64Mb), 512 mo de RAM, DirectX9.0C et en resolution 1024x728. (On ne se moque pas ! La machine me sers uniquement pour le développement ;))
Je précise car, sous OSX 10.4, il faut aussi JRE 1.6 , indisponible en MAJ. (étrange ça).
Le jeu à été tester directement sur le site (j'ai vu ta note dans la description) mais le code à été vu depuis les sources de CS.
Donc, ne le prend pas mal, mais mes "informations" venait de la version actuelle. (Sur le site).
Après, ma machine n'est pas de toute jeunesse (Octobre 2003).
Pour te répondre, il est vrai que le jeu n'égale certaines grande pointures, mais tu es seul au code & développement.
C'est déjà excellent que tu es fais ça en solo sans être démotivé au bout de x mois. (Moi j'aurais déjà lâcher l'affaire je pense).
Je re-fixe la note, avec la tête dans le brouillard, je n'ai pas fait attention sur la validation de celle-ci.
Sur ce, je retourne bosser sous L2J moi :)
A bientôt.
Cordialement,
Komona.
25 avril 2008 à 12:45
25 avril 2008 à 12:43
Je précise que le jeu aurait dû être mis à jour récemment mais que le fait de la taille importante des sources a empêché que ce soit effectué simplement. Le bug fait qu'à une certaine vitesse, les robots s'autodétruisent et le joueur aussi. C'est corrigé si vous lancez le jeu directement depuis mon site.
Les déplacements avec la souris ont été corrigés il y a quelques semaines dans la version disponible sur mon site UNIQUEMENT avec l'aide de Riven et de Bienator, deux membres de JavaGaming.org. Va voir dans la classe main.GameMouseMotionController.java, c'est la dernière méthode.
Tu cites quelques détails et tu as raison. Comme le montre la liste de requêtes de modification sur mon site, le système de gestion des collisions doit encore être amélioré. C'est vrai qu'une roquette qui explose aussi près, ça devrait faire mal.
En réalité, j'estime aujourd'hui qu'au moins 87% du code source est de mon cru. Dans les 13%, il y a une part infime dûe aux généreux coups de mains de membres de JavaGaming.org et surtout des vestiges de l'ancêtre de TUER, je parle du jeu "Art Attack" de Vincent Stahl (que je remercie encore d'avoir mis ses sources en GPL).
Enfin, je te remercie d'avoir jeté un coup d'oeil à mon code et d'avoir testé le jeu. Je précise à ceux qui n'auraient pas réussi à le lancer depuis les sources qu'il faut exécuter la cible "compile" puis la cible "run-generator" avant de se servir de la cible "run-game". Je te remercie pour la note également. Je trouvais ça un peu curieux qu'un membre m'ait mis 2/10 alors que tu remarqueras qu'il y a très peu de jeux vidéo en 3D en Java entièrement open source. Je suis encore très très loin des meilleurs FPS Java comme Jake2 et Futuristic Arenas, je manque de temps, il y a tellement à faire. Bonne continuation.
N.B: Enfin quelqu'un qui confirme que mon jeu tourne pas mal même sur des bécanes datant de 2003!!
25 avril 2008 à 07:12
J'ai pu tester très rapidement "Tuer" et voici ce qui en résulte :
Même sur une machine de 2003 (assez chargé en processus), le jeu tourne à 20/30 FPS et les déplacements sont plutôt rapide.
On vois tout de même un effort conséquent (par rapport aux premières versions)de l'optimisation du code source.
Je ne sais pas si ça viens de moi mais, les déplacements souris sont assez saccadés, cela doit venir de ma machine.
Je pense que les déplacements (Sol) pourraient être améliorés dans leur fluidité, même si ils restent bon.
Le Radius des collisions des objets aux alentours est un peu trop large à mon goût. (Détail).
Quand on tire à 10cm du mur, le personnage ne subit aucun dommages. (Détail).
Pour un jeu amateur (de plus codé en java) c'est une très bonne source, d'un côté cela fais prendre conscience que "créer un jeu 3D" n'a rien de simple et d'un autre, les fonctions et variables employés font apprendre beaucoup de chose.
Je met un 8, car d'une part, (d'après ce que j'en est lu) la source à été entièrement codé par toi-même, c'est déja quelque chose,
les améliorations effectuées avec le temps on prouver que tu savais maitriser ton code (Nombreux sont les codeurs qui ne savent pas "debug" leur sources correctement),¨
et finalement, même si le style semble "useless", il à tout de même un style.
Bonne continuation.
Cordialement,
Komona.
31 mars 2008 à 22:03
Je vais bientôt mettre à jour le code source car le jeu a pas mal évolué depuis la première fois que j'ai mis ce programme ici. Pensez à noter mon jeu si vous l'avez essayé s'il vous plaît. Bon frag.
19 févr. 2008 à 12:52
Merci beaucoup kishkaya, c'est très gentil de ta part d'avoir pris le temps de vérifier.
Bonne journée.
19 févr. 2008 à 10:40
Ca rend aussi bien que sous MSW.
A bientot
18 févr. 2008 à 12:41
Je vais donc ajouter quelques tests d'erreur supplémentaires pour détecter le matériel trop faible pour supporter mon jeu et je conseille à ceux sous Linux de prendre les pilotes les plus stables et les plus récents possibles. Ces limitations devraient disparaître progressivement principalement quand je passerai à JOGL 1.1.1 et quand mon système de subdivision de l'espace sera au point.
17 févr. 2008 à 01:24
Il est 01:18, je viens de corriger un problème abordé par truthlesslife, le fait de voir à travers les murs parce que je laissais le joueur s'avancer trop près. Je vais mettre le jeu à jour demain matin parce là, je suis vraiment complètement lessivé. J'ai perdu plusieurs heures parce que j'avais fait une troncature au lieu de faire un arrondi puis une soustraction au niveau des coordonnées des voxels des murs.
Le problème de vitesse est beaucoup plus compliqué à règler, il dépend de multiples facteurs. Je vais le règler dans un second temps.
Enfin, je vais demander à un de mes testeurs de lancer mon jeu sur Ubuntu pour essayer de reproduire le bug signalé par kishkaya. Bonne nuit.
16 févr. 2008 à 17:44
16 févr. 2008 à 14:03
Sous windows XP par contre ca marche. Je trouve le résultat sympa.
Je teste tout ce que tu me dis lundi quand je serai sur ma babass.
Kheraud
16 févr. 2008 à 10:15
Je te remercie pour ta remarque, je ne sais pas d'où ça vient. Si tu le veux bien, je vais essayer de comprendre ce qui se passe.
Tape "java -version" pour vérifier si tu utilises bien Java 1.6 (version de Sun Microsystems) et que ton système pointe bien dessus si tu as plusieurs versions de Java sur ta machine (il se peut que tu es gcj installé par défaut et que tu pointes dessus, alors utilise upadate-alternatives n'est-ce pas?).
Si possible, tape "javaws -viewer", va dans l'onglet "avancé" et coche toutes les cases de la rubrique "Débogage" et coche la case "Afficher la console" dans la rubrique "Console Java". Ensuite, relance le jeu et regarde ce qui s'affiche dans la console Java. Essaie de me faire un copier-coller du message d'erreur.
D'autre part, KISHKAYA, sache que j'apprécie beaucoup ton commentaire, tu dis exactement ce qui te pose problème, tu précises à la fois la version de ta JVM, son système d'exploitation et ton "window manager". C'est en étant aussi précis que l'on peut m'aider à corriger les rares bugs du jeu. Ton bug va être ajouté à la liste de bugs à cette adresse :
http://tuer.tuxfamily.org/project.html#bugs
Si jamais tu as le message d'erreur suivant :
java.lang.UnsatisfiedLinkError: no gluegen-rt in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
alors il te suffit de vider le cache de Java Web Start, j'ai eu ce problème sur Debian Etch sur l'ordinateur que j'utilise au travail, cela vient d'une correction d'un bug de Java Web Start sous Linux de corruption du cache qui empêche une des bibliothèques (gluegen-rt) de se charger normalement.
Autre piste, tape "xset -r off" puis "xset -r on" dans ta console. Si la commande est inconnue ou si ça ne passe pas, alors il faudra que je modifie le jeu pour traiter ce cas.
Enfin, sache que je tiens à ce que les utilisateurs de Linux soient pris au sérieux. Je mets un point d'honneur à vous satisfaire. 60% des utilisateurs de TUER sont des linuxiens. J'ai essayé avec d'autres de faire marcher le jeu sur certains unix sans grand succès depuis mon passage en Java 1.6. Ton message va permettre de garder une trace de la solution de contournement possible si d'autres gens ont le même problème que toi. 1000 fois merci. :)
15 févr. 2008 à 21:11
Je veux pas en rajouter, ca à l'air pas mal mais l'appli en utilisant Java Web start balance un ecran gris en fullscreen (il faut tuer le processus pour fermer l'appli).
Ca arrive peut être qu'a moi, je suis sous JAVA6, ubuntu//gnome
15 févr. 2008 à 13:00
12 févr. 2008 à 07:45
Tu as un sacré toupet de me dire que mon code fait peu de choses! Je fais ce que je peux. Comme tu le dis, je suis informaticien de métier, je travaille à plein temps, je ne peux donc pas consacrer tout mon temps à mon jeu. Les remarques de CIREC sont fondées, la preuve, tu radotes et tu ne me réponds toujours pas, tu ne me donnes toujours aucune précision sur ce qui t'a poussé à critiquer mes benchmarks et tu ne donnes aucune piste. J'ai demandé dans mon précédent message quelle carte graphique tu utilises, quel pilote et à quelle résolution d'écran et résultat : TOUJOURS PAS DE REPONSES PRECISES.
D'autre part, aucun mur n'apparaît blanc mais quand tu passes un peu près des murs en général, il peut arriver que tu vois à travers, ça fait une différence puisque ça ne se corrige pas de la même façon. La vitesse de déplacement n'est pas variable puisque qu'elle est calculée à partir des premières secondes d'execution du jeu une fois pour toute. Tu te contredis puisque tu disais au début que ça allait trop vite et que tu rentrais dans les murs, puis tu dis que finalement, tu n'as que 20 FPS et que c'est trop lent.
Enfin, tu es à côté de la plaque puisque ça s'est réglé calmement avec les autres membres, je n'evoie paître personne contrairement à ce que tu prétends, j'apporte des justifications quand je ne peux pas faire un truc demandé par un membre. Tu remarqueras que les autres membres ne m'ont pas parlé de ma scolarité ni traiter de prétentieux alors le commentaire de CIREC est entièrement fondé. Tu ne t'es pas demandé une seule seconde pourquoi il y a si peu de codes sources de jeux vidéo en 3D ici? Quand je t'ai demandé ton expérience dans la programmation de jeux vidéo, TU N'AS PAS REPONDU NON PLUS! Si tu me dis que tu notes pour ce que ça vaut, c'est que tu sais ce que ça vaut. Qui es-tu pour dire ce que ça vaut si tu ne justifies d'aucune expérience dans ce domaine? Tout le monde peut me mettre une note mais pas en prétendant savoir objectivement ce que ça vaut puisque ce n'est pas objectif de toute façon et que, comme le dit CIREC, il y a un manque d'objectivité flagrant. Le terme "vaut" est inadéquat puisque tu parles de valeur quand cela peut être reconnu par autrui comme une référence, une monnnaie par exemple. Donc tu notes pour ce que ça faut selon toi, ça fait une différence. Tant que tu ne seras pas plus précis sur ce que tu critiques dans mon jeu, tant que tu ne répondras pas précisément à mes questions, en effet, on tournera en rond.
Bonne journée quand même.
11 févr. 2008 à 22:53
Pour un débutant qui postait ce code en demandant de l'aide j'aurais mis 6/10 pour l'encourager. Pas parceque ce code mérite 6/10 mais parceque sont auteur aurait pu mériter des encouragement pour continuer à progresser.
Mais la les choses sont différentes : L'auteur dont nous parlons est informaticien de métier et il envoie chier tout le monde. Son code fait peu de choses et il le fait mal (certains murs apparaissent tout blanc, la vitesse de déplacement est variable, le jeu tourne globalement trop lentement etc.)... Donc je note pour ce que ça vaut.
PS : Par contre tu as totalement raison sur le fait que "j'ai attaqué directement"... Pour être honnête avant de poster mon premier commentaire j'avais lu tous les précédents commentaires et ça m'avait bien mis dans l'ambiance.
Mais vue qu'on tourne en rond j'arrête de poster sur cette source comme je l'ai déjà indiqué en PV à l'autre admin ; je ne cherche pas à me faire bannir.
Merci aux admins pour leur patience et bonne continuation à monsieur gouessej.
11 févr. 2008 à 22:49
Merci beaucoup, tu es beaucoup plus synthétique que moi. Je ne demande que ça. Je voudrais au moins savoir quelle carte graphique truthlesslife utilise, quel pilote et à quelle résolution d'écran. Ca m'aiderait à savoir quels problèmes il a pu avoir sur son PC et aussi j'ai peut-être oublié de vérifier un truc, une extension, une taille maximale de texture ou d'ensembles, tu vois ce que je veux dire? Errare humanum est. Je suis désolé pour le peu de commentaires présents dans le code, j'ai essayé de mieux commenter les nouveaux modules. Je reste ouvert aux questions, j'ai expliqué à des étudiants comment installer JOGL sous Windows et compiler mon jeu sous Eclipse 3.3 avec ANT. Bonne fin de soirée.
11 févr. 2008 à 20:19
pour moi il y a un manque d'objectivité flagrant.
Depuis le début tu critiques le code c'est ton droit, certes mais
tu commences par critiquer le coté fonctionnel du code alors que le premier message le précisait déjà ... tu ne réponds pas à ses demandes de précisions tu te contentes juste de "l'attaquer" sur un plan personnel (cursus scolaire etc) et pas un seul message avec, ne serait-ce qu'un embryon de piste pouvant mener à une amélioration du code ... par contre donner un 2 te tient à coeur.
Ce qui me fait douter de la nature de tes intentions.
11 févr. 2008 à 19:56
11 févr. 2008 à 19:49
11 févr. 2008 à 13:00
Il n'y a pas assez de place sur ce site pour mettre les sources complètes de mon jeu. Elles sont remises à jour le plus souvent plusieurs fois par semaine sur mon site web comme c'est précisé dans la rubrique "CONCLUSION". J'avais demandé à Twinuts si je pouvais faire comme ça et j'avais obtenu son accord.
Beaucoup de gens ont téléchargé les sources directement depuis mon site. De plus, je me permets de citer Twinuts qui a lu les commentaires de truthlesslife : "Laisse le se prendre pour ton psy". Ce n'est pas en m'insultant, en faisant des allusions à mon cursus scolaire, en prétendant que je diffuse de faux benchmarks et en me faisant passer pour un prétentieux et un menteur (alors que la description du jeu commence par "TUER est un modeste FPS") qu'on fera avancer mon jeu.
Si on me dit juste "mouais", en effet ça ne m'avance pas à grand chose. Je préfère quelqu'un qui me dit "mouais, tu aurais pu mettre un viseur, j'ai du mal à tirer sur les monstres" comme me l'a dit un membre d'un autre site sur un forum.
Tu parles de partage comme si je ne savais pas ce que c'est. Je te rappelle que mon jeu est en partie réutilisé dans un projet universitaire par quelques étudiants et que sur un autre forum où ça se passe mieux (je ne le cite pas pour éviter que certains aillent le pourrir), j'ai beaucoup plus de commentaires des autres membres.
Enfin, quand je relirai ça dans deux ans, je me dirai que je n'aurais pas dû accorder du temps à quelqu'un qui se prend pour mon père en me disant "Remet toi un peu en question" (je laisse sa faute d'orthographe).
11 févr. 2008 à 11:16
désolé j'ai pas eu le courage de tout lire...
il faudrait peut-être ne pas oublier où vous êtes comme l'a souligné truthlesslife : un site communautaire!
concrètement qu'est-ce que çà veut dire?
que ton appli soit extra ou juste un bon début même costaud (je fais pas de Java donc je n'interviendrai pas à ce niveau), avant d'espérer un retour tu postes pour partager!
en se fiant au compteur, 39 personnes ont téléchargé ta source. tu vois des commentaires de 39 membres différents? non! çà ne risque pas et ce n'est pas le but, même si çà apporterait beaucoup à tous.
cependant gouessej, si tu espères des retours constructifs (chose que tu avais commencé à avoir mais que tu as mal lu sans doute), ce n'est pas en rembarrant les membres qui essayent d'éplucher tes 1600 heures que tu leur extirperas des commentaires à la hauteur de ce que tu estimes.
je suis persuadé que quand tu reliras les comms dans 1 an ou 2, çà te fera sourire ;)
en attendant tu as fait des maj très rapidement et tu restes à l'écoute, n'est-ce pas le principal?
de là si un commentaire te dis "très beau boulot" ou juste "mouai...", le membre saura dans les 2 cas qu'il n'y aura pas de réponse de ta part (pourquoi faire...)
@+ et bon dev à tous
10 févr. 2008 à 22:27
Tu me traites de prétentieux et tu dis que je manque d'humilité (bien que la description de mon jeu ici commence par "TUER est un modeste FPS"), tout ça sur une base bien ténue puisque même la personne que tu m'accuses d'avoir envoyé paître a reçu par email une explication relativement détaillée pour télécharger le JDK 1.6 dans les fichiers ADC d'Apple, je ne trouve pas que c'est une mauvaise façon de traiter les gens.
Tu arrives ici en faisant des allusions maladroites et inappropriées à ma scolarité et en m'attaquant personnellement. Tu récoltes ce que tu sèmes. Tu ne devrais pas être surpris.
Je suis tout à fait ouvert aux suggestions comme beaucoup de gens l'ont remarqué sur l'ensemble des forums parlant de mon jeu (si on met de côté les provocateurs qui m'ont demandé de tout réécrire en Perl, en C/C++, en Python ou en Ruby). Si tu me parles de choses précises qui pourraient être modifiées dans le jeu, je pourrais te répondre, ça pourrait en effet m'être utile surtout si ça n'apparaît pas encore dans la liste de requêtes de modification. Je suis tout à fait conscient que mon jeu est loin d'être au point. Sur beaucoup de sites, il est précisé que le jeu est seulement en version alpha (c'est écrit ici aussi). Ce n'est pas une version stable ni complète.
Enfin, depuis le temps qu'on me dit que mon jeu n'a aucun avenir, je peux te dire que j'ai de l'espoir et il m'en faut bien pour continuer. Il faut que je te laisse, je dois aller améliorer mon "code qui tourne à 20 fps" pour reprendre tes termes. Bonne soirée.
10 févr. 2008 à 20:18
10 févr. 2008 à 17:09
10 févr. 2008 à 17:08
(http://tuer.tuxfamily.org/project.html#requests).
Tu te contredis puisque toi-même tu as dit que ça allait trop vite et le soir même, j'ai tenu compte de tes propos. Beaucoup d'internautes avaient réclamé un viseur pour pouvoir tirer plus facilement, je l'ai fait. D'autres ont réclamé une barre de progression car ils ne savaient pas où en était le chargement, je l'ai fait. Je peux citer de nombreux autres exemples si tu veux jouer à ça.
Je n'attends pas des gens qu'ils disent que mon jeu est génial, la preuve en est que sur la plupart des sites où je décris mon jeu, je commence par écrire "tiny FPS", "small FPS" ou bien "modest FPS". Par conséquent, tu es complètement à côté de la plaque.
Mes benchmarks ne sont pas fictifs. Plusieurs internautes (il me semble que Twinuts a testé le jeu, tu pourras lui demander) peuvent attester de la véracité de ces résultats. Je ne dis pas le contraire, je devrais tourner 16 fois plus vite au moins avec des graphismes aussi pauvres, c'est pour corriger ça que j'ai commencé à implémenter un algorithme de division en cellules et en portails il y a quelques mois. Je précise que pour les benchmarks, nous avons pris les pilotes qui marchaient le mieux et nous avons fait tourner le jeu à la même résolution d'écran (1280*1024) sur tous les ordinateurs pour pouvoir comparer les performances. Je dis "nous" et pas "je", la liste des gens qui ont participé à ces tests est mentionné dans le jeu, preuve que je n'envoie pas tout le monde paître.
Je te rappelle qu'il était déjà prévu que le problème de vitesse de déplacement variable d'un ordinateur à l'autre soit réglé, c'était déjà dans les cartons (mais avec un objectif plus large). J'ai juste mis au point une solution moins propre pour corriger rapidement uniquement le problème que tu as soulevé. Regarde la requête de modification titrée "add a time-based animation system".
D'autre part, le problème est que depuis le début, tu te sens obligé de te moquer de moi et de tout exagérer, tu me traites de "prétentieux", tu parles de choses qui n'ont rien à voir avec le jeu, tu tires des conclusions hatives concernant mon humilité et la façon dont je prends en compte les commentaires que laissent les internautes. Mais au cas où tu ne serais pas au courant, il y a d'autres forums qui parlent de mon jeu donc tu ne peux pas tirer des conclusions sur ma façon de m'adresser aux gens uniquement en faisant référence à celui-ci.
Enfin, je ne viens pas ici pour recevoir des leçons de morale. Je consacre énormément de temps à mon jeu, je ne me tourne pas les pouces, je vois mal comment certains de mes problèmes auraient pu déjà être réglés puisque je consacre déjà la majeure partie de mon temps libre au développement de mon jeu. Avant de me donner des leçons, pourrais-tu me dire quel est ton expérience en programmation de jeux vidéo en 3D? Sur ce, je te souhaite une bonne fin de journée.
10 févr. 2008 à 14:32
Ca ne sert non plus à rien de nous pondre des couplets pathétiques et de nous sortir des benchs plus ou moins fictif.
Le fait est que pour un jeu avec des graphismes comme ceux là tu devrais tourner à 1500 fps avec une cartes graphique de gamme moyenne.
Imagine ce qui va se passer quand tu auras du son complet, de l'IA super intélligente et des collisions impeccablement gérées !!?
Ton frame rate va être divisé par 10... Or là c'est pas possible il restera plus rien...
Remet toi un peu en question, fait preuve d'humilité car certains des tes problèmes auraient déjà pu être règlés si tu n'avais pas envoyé chier tout ceux qui t'on laissés des commentaires (Notament le problème de 'vitesse de déplacement variable' d'un pc à l'autre)...
9 févr. 2008 à 10:41
Je fais ce que je peux, je ne suis pas un artiste. Un chargeur de modèles au format MD3, OBJ et 3DS est toujours en développement dans le but de pouvoir intégrer des éléments graphiques plus complexes que ceux que tu as pu voir. Je reconnais que c'est assez pauvre graphiquement.
Je pense qu'on doit se justifier quel que soit l'ampleur du projet concerné, quelque soit sa taille.
Si tu as jeté un coup d'oeil dans le code, tu sais que tes cartes graphiques pourraient au moins me "remercier" d'utiliser quelques fonctionnalités (display lists, vertex arrays, vertex buffer objects) même si je reconnais qu'on peut aller beaucoup plus loin. C'est pourquoi depuis août 2007 j'essaie d'implémenter (en parallèle avec d'autres fonctionnalités car je ne fais pas que ça) un algorithme de division de l'espace en cellules et en portails pour grandement améliorer les performances.
Voici les résultats que j'obtiens avec mon jeu (de la carte la plus récente à la plus ancienne) :
ATI Radeon X1950 Pro AGP 8x entre 145 et 225 FPS
NVIDIA Geforce 6600 GT 90 FPS
NVIDIA Geforce 5200 FX 32 FPS
ATI Radeon Xpress 200M 32 FPS (uniquement avec la 2ème version des drivers sous XP)
ATI Radeon 9250 Pro AGP 4x/8x 17 FPS
Donc apparemment, nous n'avons pas la même définition de "machine actuelle". Avec deux cartes graphiques NVIDIA assez récente en SLI, j'obtiens en effet 400 FPS. Je ne nie pas que les performances sont trop faibles vu la faible complexité de la géométrie mais encore une fois, ta remarque est exagérée, ça tourne à 20 FPS sur des ordinateurs sorties en 2002 environ et sur des ordinateurs plus récents mais avec une carte graphique "modeste" si je puis dire.
Quand les gens postent des commentaires, j'attends un échange constructif, avec des éléments précis mis en avant pour que je puisse corriger mon jeu. Tu m'as permis d'améliorer mon jeu, j'avais prévu cette modification mais là, j'ai fait un "fix" à la va-vite (au lieu de faire un truc propre), donc je te remercie quand même. Or, si tu évitais de parler de trucs qui n'ont rien à voir avec le jeu et si tes remarques étaient plus proportionnées et si possible mieux justifiées, je n'aurais rien à y redire. Si tu m'avais dit que mon jeu tourne à 20 FPS avec des graphismes des années 90 sur des machines de moyenne gamme ayant quelques années, j'aurais été d'accord avec toi.
Petit rappel au cas où, mon code qui tourne soit disant à 20 FPS sur des machines récentes m'a demandé plus de 1600 heures de travail. J'ai dû réécrire à 85% le moteur qui a servi de base au projet, ce n'est pas facile de faire ça seul, demande à des gens qui ont de l'expérience dans la programmation de jeux. Je suis humble, je demande juste aux gens de me faire gagner du temps en parlant seulement du jeu et en étant assez précis pour que je puisse rapidement tenir compte de leurs suggestions. Les réflexions du genre "Nos cartes graphiques...ne te remercient pas du tout" et "il y a encore beaucoup de boulot" n'entrent pas dans cette catégorie.
9 févr. 2008 à 00:52
Mais bon, vue ton attitude générale et plus particulièrement l'humilité dont tu n'as pas fait preuve jusque là, je me fiche que tu trouve ma remarque déplacé et non argumenté.
Il ne faut pas oublier que tu t'enflamme pour un code qui tourne à 20 fps avec des graphismes des années 90 sur des machines actuelles...
Nos cartes graphiques qui valent la peau de trois roubignoles, ce qui je l'espère tu me l'accordera fait beaucoup pour un seul homme, ne te remercient pas du tout...
8 févr. 2008 à 23:35
8 févr. 2008 à 22:53
Enfin bref, la vitesse de déplacement est désormais quoiqu'un peu rapide devenue jouable.
Bon courage pour la suite (car je pense qu'il y a encore beaucoup de boulot !)...
8 févr. 2008 à 20:32
8 févr. 2008 à 19:10
8 févr. 2008 à 18:56
8 févr. 2008 à 14:59
28 oct. 2007 à 09:30
Maintenant, vous pouvez le lancer en moins d'une minute (connexion 100 MPS). Le code source complet reste à la même place pour le moment.
5 sept. 2007 à 13:42
Oui mon jeu requiert Java 1.6, j'aurais dû le mentionner dès le début. Au départ, le jeu fonctionnait avec Java 1.1 mais dès que j'ai utilisé JOGL, je suis passé à la 1.5. Je suis passé à la 1.6 pour des raisons que j'ai déjà données. Les apports de Java 1.6 par rapport à Java 1.5 dont je me sers indirectement ne sont pas évidents à convertir puisqu'il y a eu des corrections de bugs au niveau du son et des nio buffers, je ne vais pas répéter ce que j'ai déjà dit. Je ne vais pas réécrire complètement les nio buffers pour faire tourner ça en Java 1.5. Penses-tu aux autres utilisateurs qui profitent des bénéfices du passage à la version 1.6? Au niveau de la gestion de la taille du tas, c'est vraiment important. Quelques personnes sous Microsoft Windows et sous Debian Etch ont encore des problèmes d'écran noir, ça ne vient pas de leurs OS, ça vient du fait que sur leurs machines, il doit déjà y avoir d'autres applications qui tournent et même beaucoup. Quand Java prend de la mémoire pour le tas, il part à moins de 40 Mo ce qui est insuffisant pour gérer le jeu complètement. Je ne repasserai donc pas à Java 1.5, ce serait un retour en arrière. A mon niveau, je vois les différences de performance entre les différentes JVM, la Java 1.6 a des performances très légèrement meilleures. Je ne connais pas assez le monde Apple pour pouvoir t'aider et je ne peux pas faire une version de mon jeu juste pour les gens qui ne peuvent pas accéder aux fichiers ADC d'Apple.
Au pire, suis la démarche que je te propose, installe JOGL 1.1.0, télécharge les sources du jeu, recompile les avec le makefile et lance l'archive java du jeu. En offline, il est possible que ça marche, que ça ne plante pas si tu coupes toutes tes applications. Là, tu n'auras pas besoin de Java 1.6. Par contre, si tu as des problèmes de sons, de mode plein écran, des couleurs bizarres ou des choses de ce style, tu comprendras pourquoi je suis passé à Java 1.6. Sur certains systèmes et dans certaines conditions, en effet, Java 1.5 aurait suffit (sauf pour les nio buffers). Cependant, mon jeu se veut portable donc je ne vais pas faire un choix technique qui ne favoriserait qu'un seul OS au détriment des autres. Si je repassais à Java 1.5, celà n'avantagerait pas tout le monde.
Enfin, je ne fais pas d'infarctus, je ne m'enflamme pas. Je préfère argumenter mes choix techniques, ça fait plus sérieux quand même que "ben c'est comme ça et c'est tout". Si Java 1.5 suffisait, je ne serais pas passé à Java 1.6 car je sais que beaucoup de gens ont encore Java 1.5.
5 sept. 2007 à 05:10
Utilisation de la version JRE 1.5.0_07 Java HotSpot(TM) Client VM
Répertoire d'accueil de l'utilisateur = /Users/website
----------------------------------------------------
c: effacer la fenêtre de la console
f: finaliser les objets de la file d'attente de finalisation
g: libérer la mémoire
h: afficher ce message d'aide
m: imprimer le relevé d'utilisation de la mémoire
o: déclencher la consignation
p: recharger la configuration du proxy
q: masquer la console
r: recharger la configuration des politiques
s: vider les propriétés système et déploiement
t: vider la liste des threads
0-5: fixer le niveau de traçage à <n>
----------------------------------------------------
#### Java Web Start Error:
#### L'application a demandé une version de la plate-forme JRE (version 1.6+) qui n'est pas installée localement pour l'instant. Java Web Start n'a pas pu télécharger et installer automatiquement la version requise. Vous devez installer cette version de JRE manuellement.
la version 1.6 est disponible pour les developpeurs Apple depuis peu. Seulement je n'ai pas accès au fichiers ADC d'Apple.
Ensuite les apports 1.6 de Java par rapport à la précédente version sont plus ou moins évident à convertir sur 1.5, même si cela peut te paraître fastidieux. voilà.
4 sept. 2007 à 16:31
gouessej > faut pas s'enflamer comme ça... sinon tu risques de faire un infarctus trop jeune...
exemple j'ai bien vu des gens maintenir que les archi multi-cpu etaient instables et super mal supportées sous prétexte que nos amis de chez MS n'y arrivent pas...
^^
4 sept. 2007 à 16:21
Sinon dis moi pourquoi chez toi java 1.6 ne marche pas. Vérifie si tu as une UnsatisfiedLinkError quand tu lances "javaws -viewer". Si tel est le cas, installe libstdc++5 sur ton système. Ca ne te semble pas un peu gros de balancer sur un forum que Java 1.6 ne marche pas sur Mac Os X? Le logiciel sur lequel je travaille au boulot est en 1.6 et tourne entre autres sur Mac Os X donc excuse moi d'émettre de sérieux doutes quand tu me dis que ça ne passe pas.
Enfin, il est hors de question que je repasse en 1.5 car cela ferait réapparaitre certains bugs au niveau du son et des nio buffers qui sont très utilisés par JOGL. Si je commence à faire un script par version de Java, je ne suis pas sorti de l'auberge et je serai vite bloqué car les sources ne sont pas recompilables en Java 1.4 et certains attributs JNLP que je vais ajouter dans 2 jours ne sont supportés que par Java 1.6 (ils permettent au jeu de ne plus planter en demandant assez de mémoire tout de suite, ce n'est pas du superflu) donc cela ne règlera en rien le problème que tu rencontres.
Décris précisément ce que tu entends par "ça passe pas avec osx", donne une trace, un log, une exception, c'est trop vague pour que je puisse t'aider.
4 sept. 2007 à 01:46
2 sept. 2007 à 18:06
1 sept. 2007 à 14:58
1 sept. 2007 à 13:45
merci d'avoir reposté cette version même si elle est non fonctionnel. Elle aidera surement des gens dans la création de jeux ^^ ce même si la source manque cruellement de commentaires :P
Pour les admins : merci de ne pas supprimer cette source je lui ai demandé de procéder ainsi.