C'est un tout-en-un qui permet, comme son nom l'indique, de développer un jeu.
Par développer j'entend le fait qu'il regroupe plusieurs modules - ici graphique, audio, réseau et physique - qui facilite le travail du développeur: au lieu d'utiliser plusieurs libs comme Irrlicht, newton et openAL (3D, physique, son) par exemple, il utilise un seul "moteur de jeu" qui regroupe tout ceci.
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
Par exemple dans le cas d'Unreal Engine, on te donne un système qui intègre des modules vidéo, réseau, mais aussi un langage de script intégré, un éditeur, etc.
A l'idéal, un moteur de jeu intègre absolument tout ce qui est générique d'un jeu à l'autre: toujours avec le même exemple, pour développer UT3 ou Bioshock, les développeurs n'ont jamais eu à faire chacun la même chose, parce tout ce qui est commun aux deux jeux est dans le moteur, et pas dans le jeu lui-même. C'est le principe.
Premièrement, c'est Ungine, pas UNiGiNE (Les noms sont proches mais quand ils sont bien écrits, facilement reconnaissables l'un de l'autre).
Pour ce qui est de OGRE, je dois avouer avoir créé l'Ungine au départ pour deux raisons :
1) Je détestais l'architecture d'OGRE.
2) Je voulais savoir ce qu'il se passait derrière
Le code de l'Ungine est propre, facilement lisible, bien que j'oublie souvent de mettre des commentaires.
Par choix, je ne documente pas à l'intérieur du code, je trouve que ça réduit énormément la lisibilité, j'écrirais une documentation plus tard.
De fait, on comprend facilement les opérations réalisées par l'Ungine, que j'essaye d'optimiser niveau vitesse, bien que je sois très souvent confronté au choix vitesse/mémoire, éternel dilemme des programmeurs
Après, si on oublie le côté graphique pour l'instant, l'Ungine propose bien plus qu'OGRE ou un autre moteur graphique
Tout d'abord, désolé d'avoir écorché le nom.
Même si j'ai mal formulé ma question (par Ogre3d je n'entendais pas seulement le moteur graphique, mais aussi toutes les bibliothèques que l'on peut articuler autour), la réponse me satisfait complètement. J'espère que ce projet aboutira et qu'il sera largement soutenu par la communauté du libre. Pour l'instant, en ce qui me concerne, je n'ai pas assez de connaissances techniques pour aider, mais je serais ravi de pouvoir utiliser l'Ungine
bonjour, j'ai regarder quelques images de ton projet et les points que tu as fait,que tu vas resoudre et que tu va faire. franchement bravo il faut avoir du courage pour faire un moteur 3d.
Bon, j'ai enfin réglé un problème qui me pourchassait depuis des semaines et qui était assez ennuyeux : dès que j'osais déclarer un Ungine::RenderTexture dans le code, mes FPS tombaient à six sur mon pc portable, alors que ça fonctionnait bien sur les autres ordinateurs.
Bref, maintenant c'est réglé, et pas mal d'autres trucs aussi par la même occasion
On m'a demandé pour utiliser l'Ungine au stade alpha, ça m'intéresse beaucoup car je vais ainsi pouvoir repérer les bugs avant d'atteindre une architecture trop haut niveau (Et être obligé de recoder une grosse partie).
Du coup, je vais bientôt mettre l'Ungine sur un svn que je donnerais à certaines personnes.
Si vous êtes intéressés, dites-le moi, je préfère vous avoir via un logiciel de communication, histoire d'avoir des nouvelles très rapidement.
Ne faites pas ce choix à la légère, l'Ungine propose quelques fonctionnalités qui ne sont pas tout à fait opérationnelles actuellement, sans oublier que l'architecture n'est pas fixe.
Actuellement, seul le module graphique est disponible (Le module physique le sera après la troisième démo technique), et il propose les bases.
Mais si ça ne vous dérange pas et que vous êtes intéressés, faites-moi un petit message
Il m'a fallut un moment pour rendre le RTT fonctionnel, régler une bonne partie des bugs OpenGL, me renseigner sur OpenGL 3.1, décrocher de Minecraft et corriger quelques bugs urgents.
Ceci étant fait, j'ai commencé, il y a environ une heure, à tester le module physique, datant un peu, et je vais le remettre à niveau, corriger les bugs et probablement m'amuser un peu avec les collisions.
Ensuite, je vais préparer l'Ungine pour un test privé par quelques personnes qui se sont portées volontaires pour l'utiliser malgré son stade alpha.
Une fois ceci fait, je serais prêt à commencer la troisième démo technique, qui je le rappelle sera interactive et montrera les nouveautés du module graphique ainsi que le moteur physique.
Le moteur avance lentement mais sûrement et mes vacances à venir vont accélérer le processus.
L'Ungine n'est pas encore en alpha test, j'écris des exemples d'utilisation, qui expliquent aussi le fonctionnement de l'Ungine.
Ayant déjà écris huit exemples sur le noyau, je préfère vous envoyer les codes sources pour que vous puissiez tous voir la façon dont l'Ungine s'utilise, et pas seulement les alpha-testeurs.
Il est déjà possible d'utiliser ses propres modèles dans la seconde démo technique, il suffit de remplacer les modèles de bases par d'autres modèles (en les renommant).
Cependant, ça empêche l'utilisation du mode benchmark.
Sinon, comme j'estime que tout le monde ne se trimbale pas avec un modèle md2 sous la main, je n'envisage pas de permettre cette personnalisation avant l'arrivée de la console.
Juste une chose que je n'ai pas aimé dans les exemples, mais c'est un détail minime, je trouve que le namespace Ungine:: est un peu long, mais c'est vraiment le seul point négatif, un ung:: (par ex) aurait été plus pratique selon moi si l'on n'utilise pas using namespace.
J'ai bien aimé :
Splitter les chaines aussi simplement (je ne sais pas si c'est faisable dans la STL, je sais que ça l'est dans boost mais c'est un peu plus complexe il me semble)
le système de fichiers qui est ridiculement simple à utiliser
Le système d'évènements avec la queue d'events ET les inputs
Alors, déjà, magnifique travail. Mais en ayant vu le code source des exemples ils y a 2 ou 3 trucs qui me chiffonnent :
Les majuscules au début des noms de variables, de fonctions, d'attributs, de méthodes et de namespaces : certes tout le monde code comme il veut, mais la majorité suis cette convention. Personnellement, ça ne fait que me rebuter et m'embrouiller.
La méthode substr de l'Ungine::String me parait un peu étrange : pourquoi renvoyer chaque caractère séparé dans un éspace au lieu de renvoyer un std::vector ? (voir un Ungine::vector si tu envisage d'en faire un)
Cette dernière puce n'est pas une critique mais juste une simple question : le module Window est bien un wrapper de la SFML ?
La convention majoritaire, c'est plutôt de ne pas commencer un nom de variable par une majuscule, enfin de ce que j'en sais.
Je n'ai pas compris ta remarque pour Substr, ça renvoie une sous-chaîne selon les positions, rien d'autre.
Le module Window est un semi-wrapper, il y a quelques ajouts, mais pas grand chose donc globalement ça s'utilise comme avec la sfml.
Pour répondre à OvedrivR :
Je sais que le namespace est long, mais j'ai du mal avec "ung", je pensais à faire quelque chose à la Qt (UString, UMesh, etc), mais que faire pour les double-lettres ? (UUnicodeString).
Sinon je pensais aussi ajouter une configuration pré-processeur permettant d'utiliser le namespace ung au lieu du namespace Ungine
En effet, la convention de nommage des variables est de commencer par une minuscule, dans toutes les conventions de nommage auxquelles j'ai eu affaire, que ça soit en PHP, Python, C, Java, C++... J'ai pas souvenir d'avoir jamais lu de code sérieux ou les gens codaient avec des majuscules aux variables.
Commencer une classe ou un package par une majuscule est en revanche une convention largement suivie, précisément pour différencier des variables.
En revanche sur les fonctions ça dépend. Perso je vois souvent en minusculs et je préfère mais y'a les deux écoles.
Je respecte une certaine convention dans l'Ungine :
-Les variables commencent par une minuscule et ont une majuscule à chaque mot
-Les classes, structures, unions, méthodes, fonctions, commencent par une majuscule puis une majuscule pour chaque mot.
Dans les header, je range les méthodes par premier mot "Get" par exemple (Sauf quand il n'y en a pas), et ensuite ordre alphabétique.
De même, les variables membres sont classées par type (Pour une optimisation mémoire, bien que minime) et ensuite par ordre alphabétique.
Quant aux headers, pour l'instant ils sont en .h et utilisent le plus de forward declaration possible, mais j'envisage de créer des header sans extension (Façon Qt), qui incluraient les header plutôt que de faire une F-D.
Ceci pour éviter les dizaines d'includes nécessaires pour utiliser l'Ungine.
Après, j'hésite encore à appliquer ce procédé vu que ça risque d'apporter une certaine confusion.
Commencer une classe ou un package par une majuscule est en revanche une convention largement suivie, précisément pour différencier des variables.
C'est bien pour ça que je n'ai pas parlé des classes, structures, macros et unions .
Citation : Gwen-Haël
En revanche sur les fonctions ça dépend. Perso je vois souvent en minusculs et je préfère mais y'a les deux école.
Celle des premières lettres en minuscules pour les fonctions et méthodes est quand même largement majoritaire. D'ailleurs, à titre d'exemple, la SFML est assez critiquée pour l'utilisation de majuscules à ses premières lettres de fonctions et méthodes.
Citation : Lynix
Je respecte une certaine convention dans l'Ungine :
-Les variables commencent par une minuscule et ont une majuscule à chaque mot
-Les classes, structures, unions, méthodes, fonctions, commencent par une majuscule puis une majuscule pour chaque mot.
Pourtant, dans l'exemple de l'utilisation du core, tu écris bien Ungine::InitCore UngineCore;
, non ?
Mmmh. Projet très prometteur ! À 17 ans, créer un moteur de jeu complet et avancé est une véritable prouesse !
Félicitations, j'espère que ton projet ira loin et égalera les autres "géants" du secteur !
Pourtant, dans l'exemple de l'utilisation du core, tu écris bien Ungine::InitCore UngineCore;
, non ?
Non
Ungine::CoreInit core;
Ah ouais , je devient fou . En fait, je crois que je me suis embrouillé avec les macros UngineLog et UngineGraphics. M'enfin toujours est-il que la ligne en question où l'on initialise le core reste complètement différente de ma version.
EDIT: eh ben non, j'ai pas rêvé, y a aussi une macro UngineCore à la ligne 85. C'est troublant xD.
Les personnes volontaires pour le tester ont été contactées.
J'en ai aussi profité pour mettre à jour le pack d'exemples qui contient maintenant trois exemples de plus (Orientés sur le rendu) ainsi que les exécutables
Déjà bravo pour le travail accomplit. Cependant, je trouve ça dommage d'avoir active la syncro verticale pour les exemples.
En effet, on ne peut pas vraiment se rendre compte de la performance du moteur a cause de cela.
D'autre part, j'ai essayer la Demo numero 2, et je n'ai que ~120 FPS. Est ce normal ? Tu fait du rendu direct (glBegin ...) ? Car cela peut venir d'optimus mais j'ai bien pris le soin de le desactiver.
En fait la synchronisation verticale n'est pas activée pour les exemples, mais étrangement mes drivers NVidia ne le voient pas du même oeil (Par contre, côté ATI, aucun problème).
Pour la démo 2, la synchronisation verticale est activée, sauf pour le mode benchmark.
La démo technique 2 utilise l'immediate mode (Les Vertex Arrays) au lieu des VBO, c'est du à un oubli de ma part.
Sinon, j'ai vu que tu avais le support de 2 modeles d'objets (.obj et .md2). Je ne peut que te conseiller d'utiliser une bibliotheque externe pour faire la gestion des formats des models (Assimp).
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)