[Projet la relance] 11 Choix des libs et moteur

Voir le profil Envoyer un message privé SEB	Posté le 03 Août 2011 à 21:11
Messages : 554 GCPoints : 103313	Etant donne que tout le monde a envi d'avancer, malgré les manques qui existent encore pour pouvoir bien réaliser nos choix ici. J'ouvre ce topic qui je l'espère fera aussi débat, c'est à dire : Quels sont les libs qui seront utilisées? Pour pouvoir bien choisir il faut que les besoins soient clairs et que les renseignements que nous avons sur chacune des propositions ne soient pas des 'a priori' ou des 'il parait que' mais des certitudes si nous ne voulons pas nous retrouver devant un mur en plein milieu du dev. Nous avons donc des besoin en rendu graphique 3D, il nous faut donc choisir une lib nous permettant de faire de la 3D. Il nous faut également dequoi gérer du son, du réseau? de la physique ? utiliserons nous d'autres libs externes utilitaires? nous faut il une librairie de fenêtrage pour réaliser l'éditeur de niveau (si il est externe) ? A chaque fois sur ces libs il sera intéressant de savoir quel est leur 'niveau de popularité' ainsi que les plateformes touchés et les langages utilisés, de même il est nécessaire de savoir si nous avons vraiment besoin de cette lib ou si il est suffisamment simple de développer uniquement les quelques fonctionnalités nécessaires. Je vais donc mettre ici une liste des différents besoin que je vois, a l’intérieur nous listerons des libs cela ne veut pas dire qu'il faut absolument les utiliser mais en tout cas les considérer et j'attendrais vos propositions !! Rendu 3D (et 2D => GUI, Sprite) : Irrlicht : C++, (D3D8,9,OpenGL), (Linux, Windows, Osx), 2D GUI, Systeme de collision minimal Ogre : C++, (D3D8,9,10,OpenGL), (Linux, Windows, MacOsX), ne semble pas avoir de GUI, Physique uniquement par bindings => integration dans GCC windows un peu chiante. CrystalSpace : C++, (OpenGL), (Linux, Windows, MacOsX), GUI par la lib externe CEGUI, Physique par le module complémentaire CEL[/i] Allegro : C++, (OpenGL via allegroGL), (Linux, Windows, MacOsX, iPhone => dans allegro 5, Psp dans allegro 4.4), OpenSceneGraph : Quake engine Source engine (c pas le meme que quake? jme rapel plu) SFML SDL Rendu sonore : Fmod OpenAL : Peut utiliser direct sound par un wrapping DirectSound : (non portable) Calcul de physique : ODE Bullet PhysX Gestion réseau : RakNet Gestion des entrées commandes (Joystic, pads etc...) : DirectInput : (non portable) Gestion des threads, des collections etc... : Boost Gestion interface editeur : Qt Gtk Voila comme je l'ai dit je le répète ce sont des propositions et il n'est en aucun cas obligatoire de choisir une lib dans chaque catégorie. Dernière édition le 04 Août 2011 à 18:21 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Huntil	Posté le 03 Août 2011 à 22:31
Messages : 1012 GCPoints : 289843	Citation : Source engine (c pas le meme que quake? jme rapel plu) Si je ne m'abuse, Quake engine c'est celui du premier quake (96) qui a souvent été réutilisé, notamment pour GoldSrc le moteur de Half-life, et Source est le successeur de GoldSrc utilisé pour HL2 et dans les nouveaux jeux de Valve. Copyright © 2007 - 2010 Huntil "Il faut toujours un drame"
Voir le profil Envoyer un message privé Mod	Posté le 04 Août 2011 à 14:28
Messages : 4954 GCPoints : 2100823	Pour ce qui est du rendu sonore, des entrées et la 2d, DirectX (respectivement DirectSound, DirectInput et Direct3D Sprite/Line) sont à mon avis suffisamment haut niveau pour que l'on puisse envisager de passer directement par ceux-ci. SFML est pas mal non plus pour les entrées et la 2d, sachant qu'elle gère également nativement le son via fmod. Let's make some tweets
Voir le profil Envoyer un message privé SEB	Posté le 04 Août 2011 à 15:22
Messages : 554 GCPoints : 103313	J'ai du mal a mettre SFML ici ou même SDL car ce sont des libs très complètes et qui me paraissent donc lourdes pour être embarquées en plus d'un moteur 3D. Mais si les avis sont favorables cela me conviendra tout de même. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 04 Août 2011 à 17:56
Messages : 116 GCPoints : 23144	La SFML fonctionne avec des modules bien distincts audio/reseau/graphisme/fenêtrage. SDL ne peut servir que au fenêtrage/inputs dans notre cas. A voir avec les besoins complémentaires du moteur principal choisis.
Voir le profil Envoyer un message privé Darktib	Posté le 04 Août 2011 à 18:38
Messages : 4017 GCPoints : 347288	Si on prend Irrlicht ou Ogre, les libs 2d seront inutiles. CrystalSpace rame à mort. - Irrlicht ou Ogre (je n'ai pas de préférence) pour la puissance et la facilité de codage - OpenAL pour le son (il y a pas mal de wrappers simples) - Physique: avons-nous réellement besoin d'un moteur physique? Si tout ce que l'on a à faire, c'est des collisions sur des AAB, un moteur est inutile... - Boost: +1 ;) - Interface utilisateur éditeur: Qt, sans hésitations, pour la puissance et la facilité d'utilisation
Voir le profil Envoyer un message privé SEB	Posté le 04 Août 2011 à 19:31
Messages : 554 GCPoints : 103313	Ok dark tib :p je note bien tes remarques mais j'ai plusieurs question sur quoi te base-tu pour dire que CrystalSpace rame a mort? (je ne le soutiens pas je ne l'ai jamais utilisé mais je me demande si c'est des choses que tu as pu expérimenter ou juste des échos) Je vraiment d'accord avec toi sur le fait de dire que les libs 2D seront inutiles si nous avons déja un moteur 3D. OpenAL moi j'aime bien aussi, mais que veut tu dire par 'il y a pas mal de wrappers simples' tu parles de petites surcouches sur OpenAL? si oui peut-tu donner des noms ? Physique : on ne sais jamais... je ne dis pas que nous en aurons besoins et d'ailleur c'est en partie pour cela que j'ai dit que nous ne sommes pas obligé de choisir des libs dans toutes les cathégories. Et meme si c'est des gros moteur... cela peut jouer sur la quantité de travail a réaliser par l'équipe de GC. Boost: honètement ? -1 pour moi... franchement plus je bosse et moins j'en vois l'utilité et plutot tout les inconvénients Ceci dit ce sont de bonnes idées a prendre :p j'attend un peu la même chose de tout le monde :D NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 05 Août 2011 à 20:01
Messages : 4017 GCPoints : 347288	Je n'ai jamais programmé avec CrystalSpace. PAr contre, j'ai essayé des applications tournant avec CrystalSpace. Et ça laguait bien. Par exemple, le jeu Apricot (de la fondation blender) à été programmé ec 2 technologies: CrystalSpace et le Blender Engine (2 version du même jeu). Celle utilisant CrystalSpace ne tournait même pas sur ma machine... alors qu'avec le Blender Engine, j'atteignais 50 fps! Pour Boost, ca dépend des bibliothèques, ex: smart pointers. En fait, je pensais surtout à ne pas l'écarter dès le départ. Même si c'est la lib la plus facile à integrer (même en cours de route ;) ) Pour OpenAL, oui, je parlais de petites surcouches qui aident un peu (mais pas indispensables) par exemple: http://caudio.deathtouchstudios.com/index.html
Voir le profil Envoyer un message privé nepser	Posté le 05 Août 2011 à 20:06
Messages : 116 GCPoints : 23144	Bon personne ne se dévoue pour la faire? Bon je m'y colle alors: je propose d'utiliser le moteur de Doom3.
Voir le profil Envoyer un message privé Voir le site bebou007	Posté le 05 Août 2011 à 20:40
Messages : 238 GCPoints : 43228	moi j'aurais dit irrlicht il a l'air simple et surtout suffisant pour ce que l'on veut faire pour le moteur de doom3 faut voir si il est pas trop compliquer a prendre en main pour le petit projet que l'on veut faire
Voir le profil Envoyer un message privé SEB	Posté le 05 Août 2011 à 21:19
Messages : 554 GCPoints : 103313	Je ne sais pas si tu as dit ca pour rire ou pas (je n'ai pas vraiment saisi ton ton) nepser mais effectivement utiliser un tel moteur serait plus qu'intéressant. Le seul inconvénient que j'y vois, c'est que j'aimerais que le projet ne nécessite pas une machine de guerre pour tourner. Ce que je veux dire c'est que d'après moi un petit jeux devrai pouvoir tourner sur de petites configs. Cependant cela mériterais à être testé peut-etre. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé nepser	Posté le 06 Août 2011 à 10:17
Messages : 116 GCPoints : 23144	C'est certainement beaucoup trop gros à déployer pour ce genre de jeu, mais ça peut être intéressant de voir ce que ça contient oui.
Voir le profil Envoyer un message privé SEB	Posté le 06 Août 2011 à 13:51
Messages : 554 GCPoints : 103313	C'est toujours vraiment dur de discuter de choix quand on connais mal :/ moi le premier. Bon je vais donc présenter ici mon 'classement' et il serait bien que chacun fasse de même. Rendu 2D, 3D : Irrlicht Rendu sonore : OpenAL ou cAudio (attention cela implique peut etre une dépendance supplémentaire à Ogg Vorbis ?) Physique : bullet (si nécessaire uniquement) Réseau : on peut peut être le faire ... sinon je connais pas bcp de libs et raknet me parait bien trop gros. Entrées commandes : Direct input (malheureusement pas portable donc ... ) Gestion thread collection.. autres: pour moi rien si ce n'est la STD et coder des pti thread c pas la mort j'en ai déjà une pelleté dans mon propre moteur au pire... Interface utilisateur (essentiellement pour editeur de niveau): Qt ou Java (oui je sais c'est pas du c++ mais je trouve que pour les éditeurs c'est bien approprié aussi !) Ahh et j'oubliais pourquoi pas Spark (lib d'un membre) pour la gestion des particules si nécessaire. Dernière édition le 06 Août 2011 à 13:54 NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 06 Août 2011 à 20:19
Messages : 4017 GCPoints : 347288	+1000 pour SPARK . Il y a déjà une adaptation pour Irrlicht, mais je peut en écrire une pour Ogre si nécessaire. Pour les moteurs, je connais Irrlicht mais je n'ai pas de véritable préférence entre Irrlicht et Ogre. Sinon... tant qu'à prendre des usines à gaz... autant prendre l'UDK !
Voir le profil Envoyer un message privé SEB	Posté le 08 Août 2011 à 09:41
Messages : 554 GCPoints : 103313	Bon comme j'ai l'impression que personne n'attache trop de préférence à une lib (ce qui est très compréhensible) je pense que nous validons donc les 3 libs suivantes pour le moment : Irrlicht => 2D, 3D, gui cAudio => Son SPARK => Particules NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Voir le site stilobique	Posté le 08 Août 2011 à 15:02
Messages : 2387 GCPoints : 841900	Je tiens juste à signaler un point qui me tiens à coeur. Niveau gestion des objets 3D, un moteur qui supporte le MD5 ou le collada serait le bienvenue (___/) (='.'= )Voici Lapin. Copiez et collez Lapin dans votre signature (")_(") pour l'aider à concrétiser sa domination du monde.
Voir le profil Envoyer un message privé SEB	Posté le 08 Août 2011 à 15:18
Messages : 554 GCPoints : 103313	Je viens de vérifier, Irrlicht gère le collada 1.4 et si jamais il venait a manquer une fonctionnalité d'animation je pense pas que ce serait un souci à compléter. NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 08 Août 2011 à 22:05
Messages : 4017 GCPoints : 347288	Et pour le moteur de script ? Je pense qu'on en aura besoin, et je propose LUA.
Voir le profil Envoyer un message privé SEB	Posté le 08 Août 2011 à 22:26
Messages : 554 GCPoints : 103313	Franchement si on est tous codeur c++ et vu ce qui a été décidé je vois encore mal à quoi pourrait servir un moteur de script ici. Mais peut etre que il y aurait une très bonne raison? (je n'ai rien contre lua, je me demande simplement à quoi il serait utile ici) NextGine : 3D games engine Nombre de lignes actuel : 77683
Voir le profil Envoyer un message privé Darktib	Posté le 13 Août 2011 à 19:52
Messages : 4017 GCPoints : 347288	Je viens de télécharger le dépôt en entier (80 Mo!), j'ai une note à propos de SPARK: la version incluse est la 1.x, actuellement on en est à la 2, cependant elle n'en est pas encore complètement finalisée (mais accessible via SVN). Elle ajoute beaucoup de nouveautés, est plus rapide, etc... A mon avis, la version 2 est celle à utiliser. D'autant plus que je suis actuellement sur un éditeur d'effets utilisant SPARK2, bientôt fonctionnel. Sinon, l'utilisation de SPARK n'est pas pour tout de suite (faut tout le reste de la partie graphique avant ;) ) Pendant que j'y suis, j'ai une autre question : doc en français ou en anglais ? J'ai vu un peu des 2 dans le code pour l'instant...