Nazara Engine

En imaginant que je me lance dans la création d'un petit jeu 3D, le moteur est-il déjà pleinement fonctionnel? Je ne pense pas utiliser des fonctionnalités très poussé puisque je suis un gros débutant dans les moteurs de jeux…

Puis est-ce que les améliorations vont être rétroactive? Histoire que je sache si mon code tiendras les nouvelles version sans trop d'encombre

Hello !

Pas mal de choses sont implémentées, le moteur peut en effet déjà être utilisé pour faire des jeux 3D, après il y a quelques lacunes, notamment au niveau des animations squelettiques (elles fonctionnent mais c'est pas terrible niveau interface), autrement, bien que cela dépende surtout de tes besoins, je pense qu'il y a ce qu'il faut pour un bon début

L'API est globalement stable depuis un moment, exception faites des fonctionnalités instables ou en cours de développement (le binding Lua par exemple a changé légèrement d'interface il y a quelques jours), mais je pense commencer une liste (sur le wiki) datée des changements d'interface, avec la façon dont il faut adapter son code (même si je le répète, globalement l'interface est figée )

T'inquiète mes besoins risquent d'évoluer très doucement et ma courbe d'apprentissage risque d'être longue par le peu de temps que j'ai et le peu de connaissance actuel. Ça ne devrais donc pas poser de soucis.

Je préfère travailler sur un outil jeune ou je peux encore facilement poser des questions idiote à la communauté et surtout sur un outil libre ou je pourrais regarder concrètement ce que tu fait derrière.

Hello !

Juste un petit bulletin d'informations pour vous tenir au courant.

Alors dernièrement voilà ce qu'il s'est passé d'important:

• Le binding Lua a été optimisé: l'objet bindé est maintenant directement contenu dans la mémoire géré par Lua et non plus alloué à côté, ça enlève une déréférenciation.
• La classe Nz::Font a été bindée: on peut maintenant changer la police d'écriture de la console directement depuis celle-ci.
• Le moteur peut maintenant charger les fichiers .DDS: le support est encore expérimental, mais actuellement ça ne semble pas fonctionner avec les formats compressés pour une raison que j'ignore.
• Le support des formats de pixel est en cours de réécriture: le moteur va pouvoir connaître le format interne des formats de pixels et gérer les conversions automatiquement depuis ces informations (plus besoin d'écrire un convertisseur RGBA8 => RGB8 à la main, un algorithme va s'en charger automatiquement).
• On peut enfin récupérer la position de lecture/repositionner la lecture d'une musique (streamée)
• On peut enfin changer la technique de rendu utilisée par le SDK: malheureusement le Deferred Shading a cessé de fonctionner il y a un petit moment, le corriger est une de mes tâches à venir.
• On peut maintenant binder des composants utilisateurs

Et last but not least: j'ai commencé à travailler sur une implémentation Vulkan, depuis la sortie de Vulkan j'ai passé pas mal de temps à me renseigner sur l'API et la meilleure façon de l'utiliser, maintenant que la théorie est "acquise" je pense qu'il est temps que je passe à la pratique en expérimentant directement avec Vulkan.

Le nouveau module est fonctionnel et permet de charger quelques fonctions de Vulkan, récupérer des informations sur son GPU, pas encore de rendu pour le moment mais ça ne saurait tarder.

Je tiens à préciser, le support de Vulkan est prévu mais ça prendra quand même un moment avant qu'il arrive car son arrivée demande une réécriture complète du module de rendu et une partie du module graphique, je vais orienter le nouveau module de rendu vers une architecture dynamique: il sera possible de choisir entre Vulkan/OpenGL/Autre (Metal/DX?) au chargement de l'application, cela afin de supporter un maximum d'applications (pour les ordinateurs encore trop nombreux ne supportant pas Vulkan, pour les iDevice, etc.).

J'ai également commencé l'écriture du tutoriel "00", expliquant ce qu'est Nazara, comment le télécharger et le compiler avant de pouvoir l'utiliser, c'est ma priorité du moment, ça et la conception d'un plugin Assimp (permettant de supporter beaucoup plus de formats que le .md2, .obj et .md5mesh actuels).

Une fois que le tutoriel sera suffisamment avancé et le moteur suffisamment utilisable (je pense au retour du Deferred Shading et des particules, et pourquoi pas des ombres, après tout elles fonctionnent), je pense me lancer dans la conception d'un petit jeu, avec pourquoi pas la participation de certains d'entre-vous

Voilà !

Woah! Décidément tu es plus que surprenant! J'ai hâte de voir ton tutoriel 00, avec un peu de chance il tombera a temps pour mon lancement et je pourrais ainsi servir de béta-testeur.

J'ai commencé à suivre le projet très récemment, et ma foi, ça envoie de la pizza aux moineaux (si je puis dire) xD

En tout cas je suis super impressionné par le résultat actuel, j'attends de voir la suite Bon courage à toi !

Et voici les débuts du Tutoriel 00, avec les explications pour compiler le moteur sous Windows avec Visual Studio 2015 et tousse Code::Blocks.
Par ici !

Désolé pour ceux qui ne sont pas concernés par ces deux compilateurs ou par Windows, votre tour viendra mais j'aimerai d'abord étudier la possibilité de simplifier la compilation sous Linux, car en ce moment elle est assez ardue.

J'en profite également pour vous dire que le plugin Assimp est là, du moins pour les meshs statiques, la structure employée par Assimp pour les meshs squelettiques est assez énigmatique.

Concernant Vulkan, je tiens à dire que c'est vraiment une API très complexe et difficile, il y a eu du progrès mais toujours pas de rendu pour le moment.

Merci à tous pour vos encouragements, ça fait toujours plaisir !

Hello, Comme je vais partir en vacances en Belgique à partir de demain jusqu'à la fin du mois, je vous fait un petit bulletin d'infos sur les nouveautés depuis la dernière fois:

• Pour faciliter le développement Windows (avec Visual Studio notamment), les .dll dont ont besoin les exécutables de Nazara sont maintenant copiés automatiquement, à la compilation, dans le dossier examples/bin.
• La réécriture des formats de pixel a été bien avancée, jusqu'ici les seuls changements visibles sont au niveau du loader DDS qui devrait maintenant être en mesure de reconnaître tous les formats supportés (à l'exception des formats de plus de 64 bits par pixel pour l'instant).
• Le plugin Assimp charge maintenant les matériaux.
• Des matériaux de base pour la 2D sont maintenant disponibles.
• Il est maintenant possible de changer explicitement la taille d'un fichier, permettant notamment de le réduire. (J'ai eu besoin de cette fonctionnalité donc la voilà intégrée).
• Les ombres dynamiques sont intégrées au moteur ! (Il manque le support des lumières directionnelles pour l'instant).
• Le wrapper Vulkan avance très bien.

Concernant Vulkan, on a passé un nouveau stade: le wrapper est suffisamment avancé pour gérer l'ouverture d'une fenêtre avec Nazara et faire un rendu Vulkan à l'intérieur (pour l'instant c'est un clear color, rien de très intéressant à voir), et surtout: je comprends ce que je fais

Au final, plus j'avance et découvre Vulkan, plus cette API me plaît et ne semble pas être aussi compliquée qu'au premier abord (elle semble même remarquablement bien fichue).
J'avance à tâtons cependant, je n'ai encore gratté que la surface de l'API et je suis encore loin du compte, mais j'espère pouvoir fournir un rendu Vulkan basique intégré à Nazara plus vite que prévu

Bref, je vous dis à dans une semaine et merci à vous tous pour votre soutien

Je trouve ton idée intéressante @Folaefolc. C'est vrai que quand le projet sera stable certaines personnes pourront se coller la dessus, c'est toujours intéressant.

Cependant il est peut être possible d'intégrer ça sous forme de plugin à un software déjà existant.

Dans tout les cas c'est un gros travail qui ne faut pas sous-estimer.

PS: Le système de rating commence par me sortir par les trou de nez.. J'ai pleuré quand il était apparu sur SdZ et je retrouve exactement les mêmes comportement exaspérant ici.

Mon but n'est pas d'imiter les moteurs du même genre d'Unity, mais de fournir un outil de qualité qui soit ouvert, et disons plus centré sur le code qu'Unity.

Bien sûr à terme (d'ici pas si longtemps que ça d'ailleurs !), j'aimerai avoir un éditeur simple, permettant de placer des entités dans un niveau pouvant être chargé directement par le moteur.
J'ai aussi commencé à étudier la possibilité de faire un débuggueur Lua, permettant de placer des points d'arrêts dans un script Lua, de suivre l'exécution ligne par ligne, afficher les valeurs des variables locales, etc.
Bien sûr pour ça, il me faudrait faire un petit IDE intégré pour Nazara, on part alors dans les trucs pas-vraiment-prioritaires, mais à prévoir.

Je pense que la priorité à court terme doit rester l'établissement d'une communauté autour de Nazara, et donc rendre le moteur suffisamment stable pour être intéressant, avec de bons tutoriels (et continuer à étudier l'implémentation Vulkan, histoire d'avoir un bon argument technique pour le moteur).

Tout ça pour dire, je suis revenu de congés

Bonjour,

Je viens d'essayer de compiler Nazara sous linux (Édit : Opensuse 42, uname -a renvoie Linux 4.1.21-14-default x86_64 GNU/Linux). Et c'est la merde.

Je récupère les sources, et premake4 depuis les dépôts. Un petit premake4 --help pour comprendre comment il marche (tiens, pas de man, il faut forcement faire --help ?).

Bon, premake4 gmake premake4-linux, ça marche. Je vais dans le dossier gmake, je tape make. Première erreur, mon gcc par défaut est gcc4.8, trop vieux. J'installe gcc5.3 depuis les paquets, fait pointé la commande g++ sur g++-5 plutôt que g++-4.8 car je n'ai pas réussi à forcer un compilateur en particulier, ni dans Makefile, ni dans le premake.

Je relance make, deuxième erreur.

/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: Aucun fichier ou dossier de ce type

Hum… ls /usr/include/gnu/ retourne libc-version.h lib-names.h stubs-64.h stubs.h, pourquoi diable ne veut-il pas récupérer ce qui existe ? Qu'à cela ne tienne, je fais sudo ln -s /usr/include/gnu/stubs-64.h /usr/include/gnu/stubs-32.h, et ça compile (note, j'ai d'abord essayer avec stubs.h ça plantait).

Troisième erreur (vu les bidouilles que j'ai du faire, ce n'est plus vraiement étonnant),

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

==== Building NazaraCore (debugdynamic32) ====
Linking NazaraCore
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: escamotage incompatible /usr/lib64/gcc/x86_64-suse-linux/5/../../../libdl.so lors de la recherche de -ldl
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -ldl
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: escamotage incompatible /usr/lib64/gcc/x86_64-suse-linux/5/../../../libpthread.so lors de la recherche de -lpthread
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -lpthread
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: escamotage incompatible /usr/lib64/gcc/x86_64-suse-linux/5/libstdc++.so lors de la recherche de -lstdc++
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: escamotage incompatible /usr/lib64/gcc/x86_64-suse-linux/5/libstdc++.a lors de la recherche de -lstdc++
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -lstdc++
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: escamotage incompatible /usr/lib64/gcc/x86_64-suse-linux/5/../../../libm.so lors de la recherche de -lm
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -lm
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: escamotage incompatible /usr/lib64/gcc/x86_64-suse-linux/5/libgcc_s.so lors de la recherche de -lgcc_s
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -lgcc_s
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: escamotage incompatible /usr/lib64/gcc/x86_64-suse-linux/5/../../../libc.so lors de la recherche de -lc
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -lc
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: escamotage incompatible /usr/lib64/gcc/x86_64-suse-linux/5/libgcc_s.so lors de la recherche de -lgcc_s
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -lgcc_s
collect2: error: ld returned 1 exit status
NazaraCore.make:195: recipe for target '../../../lib/gmake/x86/libNazaraCore-d.so' failed
make[1]: *** [../../../lib/gmake/x86/libNazaraCore-d.so] Error 1
Makefile:20: recipe for target 'NazaraCore' failed
make: *** [NazaraCore] Error 2
[1]    23233 exit 2     make

mais là, je sèche. D'autant plus que j'ai bien un fichier /usr/lib64/libdl.so.

C'est la première fois que je tombe sur premake. Et j'aime pas.

Utilise les binaires de premake 5 fournis dans le dossier, il y a des chances que ça fasse le café

Version courte, ça n'a pas marché aussi facilement que tu l'espérais (et finalement, ça ne marche pas), je retombe sur une erreur cryptique.

Premake5 n'a pas suffi, même erreur. J'ai cependant trouvé la source de l'erreur : premake colle tout par défaut en 32 bits. Il faut modifier la ligne,

1
2
3

ifndef config
  config=debugdynamic_x32
endif

en

1
2
3

ifndef config
  config=debugdynamic_x64
endif

et ça fait le link.

Je suis tombé sur plusieurs erreur de noms :

• dans NazaraAudio.make, j'ai dû remplacer -lsndfile-1 par -lsndfile pour qu'il le trouve ;
• dans NazaraUtility.make, j'ai dû remplacer -lfreetype-s par -lfreetype. J'ai aussi dû supprimé -lstb_image après avoir vainement tenté de le lui donner (téléchargé, copier dans les emplacements standards, pas de réponse) ;
• pour NazaraGraphics, il me signale un fichier mal formaté : dans DepthRenderTechnique.hpp, ligne 77, il faut remplacer #include <Nazara/Graphics/dEPTHRenderTechnique.inl> par #include <Nazara/Graphics/DepthRenderTechnique.inl>.

Et voilà que ça plante lors de NazaraPhysics… L'erreur,

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

==== Building NazaraPhysics (debugdynamic_x64) ====
Creating obj/x64/DebugDynamic/NazaraPhysics
NewOverload.cpp
Geom.cpp
PhysObject.cpp
PhysWorld.cpp
Physics.cpp
Linking NazaraPhysics
/usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -lnewton
collect2: error: ld returned 1 exit status
NazaraPhysics.make:141: recipe for target '../../../lib/gmake/x64/libNazaraPhysics-d.so' failed
make[1]: *** [../../../lib/gmake/x64/libNazaraPhysics-d.so] Error 1
Makefile:118: recipe for target 'NazaraPhysics' failed
make: *** [NazaraPhysics] Error 2
[1]    10490 exit 2     make

problème, libnewton est un nom un peu trop commun, je ne parviens pas à trouver de quel bibliothèque il s'agit.

Tu parlais juste au-dessus d'établir une communauté. Je pense qu'il te faudra soit simplifier fortement la compilation (inclure les bibliothèques inhabituelles et faire en sorte que premake créé un makefile qui marche sans devoir être modifié), ou bien proposer des binaires pré-compilés. Car là, c'est un peu compliqué…

@Gabbro Je suis au courrant des problèmes liés à la version Linux. Mais j'attendais d'être capable de faire une demande de fusion avant d'en parler avec Lynix. Au cas où j'avais écrit des instructions après une installation sur une machine virtuelle vierge (Ubuntu 16.04): readme

En repartant de 0, et en suivant tes consignes, j'ai quand même les modifications supplémentaires suivantes à faire :

-lsndfile-1 et -lfreetype-s doivent être rempalcés par -lsndfile et -lfreetype dans les fichiers NazaraAudio.make et NazaraUtility.make respectivement. La modification dans DepthRenderTechnique.hpp, idem. Je dois virer l'option -std=c++14 dans le fichier stb_image.make (qui est associé à ALL_CFLAGS, c'est-à-dire aux options C, guère étonnant qu'il n'aime pas des options c++).

Je link NazaraUtility sans soucis, et tombe sur une nouvelle erreur cryptique en compilant NazaraRenderer,

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

==== Building NazaraRenderer (debugdynamic_x64) ====
Creating obj/x64/DebugDynamic/NazaraRenderer
ContextParameters.cpp
Context.cpp
../../../src/Nazara/Renderer/ContextParameters.cpp:35:1: fatal error: opening dependency file obj/x64/DebugDynamic/NazaraRenderer/ContextParameters.d: Aucun fichier ou dossier de ce type
 }
 ^
compilation terminated.
NazaraRenderer.make:204: recipe for target 'obj/x64/DebugDynamic/NazaraRenderer/ContextParameters.o' failed
make[1]: *** [obj/x64/DebugDynamic/NazaraRenderer/ContextParameters.o] Error 1
make[1]: *** Attente des tâches non terminées....
NazaraEngine.make:144: recipe for target 'NazaraRenderer' failed
make: *** [NazaraRenderer] Error 2
[1]    17945 exit 2     make -j3 -f NazaraEngine.make

sauf que je ne vois pas d'erreur dans le fichier ContextParameters.cpp:35, et que ça ne ressemble pas à un problème de dépendance.

Je vous ai pris de court ce matin

Voici quelques commits qui devraient améliorer la situation sous Linux, j'ai pour ma part réussi à compiler le moteur sans souci avec ça.

• Commit 1 (Corrige la casse de l'include)
• Commit 2 (Corrige le choix par défaut du makefile ainsi que le link des exemples avec le SDK)
• Commit 3 (Corrige le nom des bibliothèques sous Linux).

Il manque les binaires Linux pour Newton, je les ai compilé ce matin (en 64 bits, je n'ai pas encore réussi à suffisamment bidouiller le makefile pour la version 32 bits) mais je n'ai pas eu le temps de push.

Je commence à me rendre compte que le côté multiplateforme de Nazara intéresse plus de monde que prévu, et donc que je devrais aussi contenter les développeurs Linux, c'est maintenant un premier pas qui est effectué, une fois les binaires en ligne, il ne manquera plus qu'un petit tutoriel.

Ah oui, dernière petite précision, au sujet de STB et Lua: Il faut compiler les dépendances de Nazara, et donc appeler premake avec l'argument –with-extlibs (ce qui implique par la suite de sélectionner le fichier Makefile à la main, avec make -f), je regarderai aussi pour les mettre directement en ligne comme pour Windows.

Développeurs Linuxiens: Je vous ai compris \o/

Newton Dynamics.

Pour ton souci de compilation du Renderer, là par contre je n'ai pas de piste, je n'ai pas eu ce problème en compilant sur ma machine virtuelle ce matin (Ubuntu).

Ça compile quasiment.

Truc drôle, NazaraLua a échoué dans un premier temps, puis a marché quand j'ai relancé la même commande.

J'ai dû changer -lnewton en -lNewton dans NazaraPhysics.make. Le module NazaraUnitTests ne link pas, car,

1
2
3
4
5
6
7
8

Linking NazaraUnitTests
../../../lib/gmake/x64/libNazaraPhysics-d.so: référence indéfinie vers « NewtonBodyGetMassMatrix »
collect2: error: ld returned 1 exit status
NazaraUnitTests.make:171: recipe for target '../../../tests/NazaraUnitTests' failed
make[1]: *** [../../../tests/NazaraUnitTests] Error 1
NazaraEngine.make:178: recipe for target 'NazaraUnitTests' failed
make: *** [NazaraUnitTests] Error 2
[1]    5581 exit 2     make -f NazaraEngine.make

Les tests, c'est pas catastrophique, mais les exemples plantent avec le même message.

Je commence à me rendre compte que le côté multiplateforme de Nazara intéresse plus de monde que prévu, et donc que je devrais aussi contenter les développeurs Linux, c'est maintenant un premier pas qui est effectué, une fois les binaires en ligne, il ne manquera plus qu'un petit tutoriel.

Bah, disons que compiler sur ma machine reste l'étape 0 pour développer avec.

Actuellement, les commandes lancées sont

1
2
3
4
5

chmod +x ./premake5-linux
./premake5-linux --with-extlibs --with-examples gmake
cd gmake
make -f NazaraExtlibs.make -j3
make -f NazaraEngine.make -j3    (deux fois)

et pour compiler un test, ce devrait être un truc du genre g++ -I"/home/moi/Bin/NazaraEngine/include/" -L"/home/moi/Bin/NazaraEngine/lib/" -I"/home/moi/Bin/NazaraEngine/SDK/include/" -L"/home/moi/Bin/NazaraEngine/SDK/src/" test.cpp -std=c++14 (en ajustant le chemin, bien évidemment). Mais je ferai un vrai essai quand j'aurais réussi la compilation.

Il faut compiler Newton 3.13, pas master.

Je vais m'occuper de Newton ce soir si je peux, mais la liste des choses à faire pour compiler Nazara s'est déjà dramatiquement réduite

La compilation de Nazara a marché avec Newton 3.13.

Merci beaucoup.

Je ne sais pas si tu tiens une liste des dépendances quelque part, j'ai dû installé au moins

1
2
3
4

sndfile
freetype
assimp
xcb-util

Je pense que ce serait bien que les 5 commandes chmod/make de mon message du dessus soient mises dans le wiki.

Je tente une utilisation sur des cas test bientôt, je fatigue un peu, là.

J'ai mis en place les nouvelles bibliothèques, je me suis aperçu que j'utilisais Newton 3.8, j'ai donc fait la mise à jour vers Newton 3.13 et mis à jour les bibliothèques Windows et Linux.

J'en ai aussi profité pour ajouter les binaires précompilés pour les bibliothèques externes sous Linux, pour une raison obscure il faut quand même préciser à gmake qu'on veut inclure le Makefile des bibliothèques externes pour les utiliser cependant (sinon il ne les trouve pas).

Par contre, je ne sais pas si je me suis raté au niveau des binaires de Newton, mais j'échoue à chaque fois sur:

Linking DemoFirstScene ../../../lib/gmake/x64/libNazaraPhysics-d.so: référence indéfinie vers « dgBroadPhaseDefault::dgBroadPhaseDefault(dgWorld) » ../../../lib/gmake/x64/libNazaraPhysics-d.so: référence indéfinie vers « dgBroadPhasePersistent::dgBroadPhasePersistent(dgWorld) »

Si vous pouviez tester de votre côté, et dans le cas où ça ne marche pas m'envoyer vos binaires Newton (release, 32 et 64 bits).

Le dernier truc qui manque (mis à part le tutoriel) du coup, c'est le fameux "make install", c'est un problème connu de Premake, je ne sais pas s'il a été résolu ou pas, mais je peux simuler son fonctionnement.

Bref, on y est presque