Nazara Engine

Moteur de jeu libre en C++14

a marqué ce sujet comme résolu.

Tiens moi j'ai un question en tant que Artist 3D, tu n'en est peut être pas la mais au niveau des shaders c'est du PBR ?

stilobique

Pas pour l'instant, c'est du simple Phong Lighting, mais le PBR fait partie des choses prévues (et si j'ai bien compris, ce dont je doute toujours, ça n'entraîne qu'une modification des matériaux et le rajout de nouveaux ÜberShader).

+0 -0

Bonjour tout le monde,

Une grande nouvelle pour les linuxiens, les deux derniers modules du moteur (Utility et Renderer) ont été finalement portés. Le module Core ayant déjà été effectué par danman. Voici une capture d'écran de la scène d'exemple sur mon Ubuntu:

Nazara on Ubuntu

D'un point de vue technique, mon choix s'est porté sur l'utilisation de la bibliothèque logicielle XCB (implémentation féline du protocol X Window System) pour la gestion des fenêtres et de l'interface de programmation GLX pour la création d'un contexte OpenGL.

Le portage vers Linux n'est pas complet. En ce sens que certaines fonctionnalités ne sont pas encore tout à fait implémentées. Mais les besoins liés à une 'utilisation classique' sont normalement parfaitement remplis. Si vous avez des corrections ou améliorations à apporter au code, vous pouvez toujours m'en faire part.

Vous trouverez sur ma branche les instructions nécessaires à la compilation du projet. Préparez une bonne dose de courage, vous en aurez besoin =) Je n'ai pas eu le cœur d'essayer mes instructions sur une machine vierge. Si vous rencontrez des difficultés, vous pouvez m'envoyer un message en privé. J'éditerai ce message si des questions se répètent.

Prochaine étape, un début de documentation ?

+4 -0

Bonjour !

Déjà félicitation pour le portage, je n'ai pas encore essayé, mais j'avoue m'être bien ramassé en ayant essayé de faire le portage de mon côté !

Je pointe aussi ce soucis : https://github.com/SFML/SFML/pull/934 Je ne sais pas si vous l'avez corrigé, mais je testerai à défaut !

Merci beaucoup, en tout cas !

PS : le lien ne fonctionne pas à cause des espaces et % qui sont transformés.

J'ai testé la compilation aussi, j'ai la même erreur qu'avant avec les parser.o et loader.o (multiple definition parce que ça écrase les fichiers précédents). La modification de Lynix sur le master a été prise en compte ?

+0 -0

Lors d'un échange de mails avec binary1248, il m'avait fait part de ce problème. Seulement ce n'est que la partie émergée de l'iceberg, la situation actuelle de XCB est très loin d'être stable. En effet, de nombreux problèmes n'ont toujours pas été réglés (après 14 ans de développement !):

  • XCB a-t-il réellement remplacé Xlib ? Sachant qu'actuellement, des fonctions de Xlib sont implémentées en terme de XCB (XTrans).
  • l'interaction avec GLX.
  • XInput, XIM et X KeyBoard qui sont trop fortement couplés et mal (ou simplement pas) traduits en XCB.
  • le manque de documentation ou d'exemples sur le net !

Disons que pour le moment, j'attends que les choses évoluent du côté XCB avant de peut-être m'y replonger. En outre, convertir la gestion des événements en celle de Xlib devrait être une opération relativement aisée pour celui qui en aurait réellement l'usage.

Je n'ai pas rencontré le problème de multiples définitions des fichiers (parser et loader), peut-être suffit-il renommer les fichiers de manière unique ?

+0 -0

Lors d'un échange de mails avec binary1248, il m'avait fait part de ce problème. Seulement ce n'est que la partie émergée de l'iceberg, la situation actuelle de XCB est très loin d'être stable. En effet, de nombreux problèmes n'ont toujours pas été réglés (après 14 ans de développement !):

  • XCB a-t-il réellement remplacé Xlib ? Sachant qu'actuellement, des fonctions de Xlib sont implémentées en terme de XCB (XTrans).
  • l'interaction avec GLX.
  • XInput, XIM et X KeyBoard qui sont trop fortement couplés et mal (ou simplement pas) traduits en XCB.
  • le manque de documentation ou d'exemples sur le net !

Disons que pour le moment, j'attends que les choses évoluent du côté XCB avant de peut-être m'y replonger. En outre, convertir la gestion des événements en celle de Xlib devrait être une opération relativement aisée pour celui qui en aurait réellement l'usage.

Peut être que Wayland peut devenir envisageable si EGL peut implémenter tout ce que Nazara a besoin ? Après tout ca fonctionne pour l'unreal engine.

Je n'ai pas rencontré le problème de multiples définitions des fichiers (parser et loader), peut-être suffit-il renommer les fichiers de manière unique ?

Gawaboumga

Dans mon cas, il s'agit de la même erreur qu'avant, les cibles makefile sont les mêmes pour les sous-dossiers, quand le nom du fichier est le même dans deux sous-dossiers :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
NazaraUtility.make:323: avertissement : surchargement de la recette pour la cible « obj/DebugDLL/NazaraUtility/Loader.o »
NazaraUtility.make:319: avertissement : ancienne recette ignorée pour la cible « obj/DebugDLL/NazaraUtility/Loader.o »
NazaraUtility.make:327: avertissement : surchargement de la recette pour la cible « obj/DebugDLL/NazaraUtility/Loader.o »
NazaraUtility.make:323: avertissement : ancienne recette ignorée pour la cible « obj/DebugDLL/NazaraUtility/Loader.o »
NazaraUtility.make:335: avertissement : surchargement de la recette pour la cible « obj/DebugDLL/NazaraUtility/Loader.o »
NazaraUtility.make:327: avertissement : ancienne recette ignorée pour la cible « obj/DebugDLL/NazaraUtility/Loader.o »
NazaraUtility.make:343: avertissement : surchargement de la recette pour la cible « obj/DebugDLL/NazaraUtility/Loader.o »
NazaraUtility.make:335: avertissement : ancienne recette ignorée pour la cible « obj/DebugDLL/NazaraUtility/Loader.o »
NazaraUtility.make:347: avertissement : surchargement de la recette pour la cible « obj/DebugDLL/NazaraUtility/Loader.o »
NazaraUtility.make:343: avertissement : ancienne recette ignorée pour la cible « obj/DebugDLL/NazaraUtility/Loader.o »
NazaraUtility.make:351: avertissement : surchargement de la recette pour la cible « obj/DebugDLL/NazaraUtility/Parser.o »
NazaraUtility.make:331: avertissement : ancienne recette ignorée pour la cible « obj/DebugDLL/NazaraUtility/Parser.o »

Ce problème a été réglé depuis belle lurette sur la branche expérimentale (NDK), je vais merge le master dans NDK et je te suggère de réessayer avec cette branche-là :)

Edit: Quant à Wayland et surtout EGL, aucune idée, ça dépend vraiment.

+0 -0

Hello !

Alors pour ceux qui l'ont remarqué, les images en première page (ainsi que tous les liens vers le nom de domaine digitalpulsesoftware.com) sont morts, pour la simple raison que j'ai changé d'hébergement et eu des problèmes à faire la transition du nom de domaine, et celui-ci a été racheté par un merveilleux service qui me demande 500$ pour le récupérer (donc nous attendrons que je roule sur l'or).

C'est pourquoi tout a été déplacé vers le nom de domaine digitalpulsesoftware.net, qui est hébergé sur mon serveur dédié, j'ai changé les images en première page en fonction mais il y a sans doute pas mal de liens morts qui traînent, il suffit de remplacer le .com par le .net pour corriger ça :)

Concernant le moteur lui-même, il n'est pas en pause une fois de plus (malgré le manque d'activité sur le dépôt GitHub), c'est simplement que je travaille sur un nouveau module (j'ai nommé le réseau) et attend d'avoir une implémentation fonctionnelle avant de l'envoyer en ligne :)

Je pense que je vais faire quelque chose d'intéressant au niveau des démos pour le réseau, profiter de mon serveur dédié pour permettre aux testeurs de se connecter à un seul et unique serveur (et donc de se retrouver sur un même endroit, pourquoi pas pour une démo de chat).

Je pense, une fois le module réseau terminé, me concentrer sur la création de pas mal de petites démos pour apprendre à utiliser le moteur, en attendant une documentation convenable.

Keep going!

+6 -0

Hello.

Je suis loin d'être un développeur 3D, mais ça fait toujours plaisir de voir des projets tel que le tiens. Je voulais savoir si tu étais toujours motivé et avoir un peu des news sur Nazara :)

A mon humble avis, je pense que ton dernier post mets en avant un aspect qui permettrait à ton moteur un grand succès : les "démos pour apprendre à utiliser le moteur".

Beaucoup de développeur n'ont pas franchement le courage de se lancer dans l'univers 3D, tellement vaste et complexe à la fois. Il y a beaucoup de notions a comprendre, connaître. Des vidéos explicatives de fonction du moteur serait un gros plus et devrait vraiment aider à faire connaitre Nazara et aux développeurs hésitant de se lancer ;-)

Ce n'est qu'un avis !

Bon c'est bien beau tout ça mais maintenant que les specs de Vulkan sont sorties va falloir tout refaire…
Ou du moins adapter l'OpenGL existant. ^^

Non plus sérieusement, c'est prévu sur le long terme ?
J'avoue que c'est un sujet qui m’intéresse tout particulièrement. Et pour Nazara ce serait une sacré force de proposer quelque chose de 100% à jour (dans le sens ou il se démarquerait des autres moteurs).

+3 -0

Bon c'est bien beau tout ça mais maintenant que les specs de Vulkan sont sorties va falloir tout refaire…

Loptr

Hé bien heureusement que j'ai pensé le moteur de façon modulaire (tout ce qui est OpenGL se trouve dans une partie cloisonnée - à 99% - du moteur).

Non plus sérieusement, c'est prévu sur le long terme ?
J'avoue que c'est un sujet qui m’intéresse tout particulièrement. Et pour Nazara ce serait une sacré force de proposer quelque chose de 100% à jour (dans le sens ou se démarquerait des autres moteurs).

Loptr

C'est prévu oui, à long terme cependant :)
Maintenant que j'ai un module de rendu stable et pas trop dégueulasse, je n'envisage pas de le recommencer avant d'avoir un minimum de maîtrise de Vulkan (parce que j'avoue que jusqu'ici je suis assez perdu dans les codes d'exemples, j'attends quelque chose d'un peu plus documenté).

Donc Vulkan oui, mais pas tout de suite (je risque de commencer une ébauche d'un nouveau module de rendu d'ici quelques semaines dans une autre branche, mais elle ne risque pas d'être à terme tout de suite, j'ai d'autres priorités).

Actuellement je suis sur le réseau, qui est une étape nécessaire pour mon futur projet de démo utilisant Nazara :)

Au passage, suite à vos nombreuses réactions sur le topic du concours, je vais commencer une petite série de démos documentées, chacune présentant une facette différente du moteur, à défaut d'avoir un tutoriel (que je n'ai clairement pas le temps d'écrire maintenant).

+6 -0

Salut les agrumes !

Ça faisait longtemps que je n'avais donné beaucoup de nouvelles du moteur, et rassurez-vous tout se passe bien !

Je travaille sur plusieurs fonctionnalités en même temps, que ce soit le réseau, la nouvelle interface haut-niveau du moteur ou encore le binding Lua, sans oublier l'écriture d'un tutoriel (si si !).

Alors pour prendre ces choses dans l'ordre, mon protocole RUdp est très expérimental et arrive à perdre des packets, je dois enquêter sur la chose et le tester davantage.

Concernant l'interface haut-niveau du moteur, nous nous retrouvons avec ceci:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
int main()
{
    Ndk::Application application;

    Nz::RenderWindow& mainWindow = application.AddWindow<Nz::RenderWindow>(Nz::VideoMode(800, 600, 32), "Test");

    Ndk::World& world = application.AddWorld();

    while (application.Run())
    {
        Nz::WindowEvent event;
        while (mainWindow.PollEvent(&event))
        {
            if (event.type == Nz::WindowEventType_Quit)
                application.Quit();
        }

        mainWindow.Display();
    }

    return EXIT_SUCCESS;
}

On voit donc une nouvelle classe Application, unique dans le programme et responsable de la vie des fenêtres et du monde, ainsi que de leur mise à jour, en effet la méthode Run() s'occupe de la mise à jour des mondes et de détruire les fenêtres si elles ont été fermées durant la boucle de rendu.

La gestion des événements est toujours la même, celle inspirée de la SFML, dont j'essaie de me débarrasser depuis un moment déjà.

À ce propos, je pensais gérer les événements via le système de signaux, ce qui donnerait quelque chose comme:

1
2
3
4
5
    Nz::RenderWindow& mainWindow = application.AddWindow<Nz::RenderWindow>(Nz::VideoMode(800, 600, 32), "Test");
    mainWindow.OnKeyPressed.Connect([] (KeyEvent& event)
    {
        std::cout << "Une touche a été pressée !" << std::endl;
    });

Mais j'ai peur que ce système ne soit pas assez user-friendly, j'enquête toujours.

Sinon, concernant le binding Lua et la console, disons que les choses ont beaucoup progressé, à voir en images (animées):

(Oh et bien entendu, Nazara va devenir un plugin pour Unity 3D, d'ailleurs je dois tout réécrire en C# !).

+7 -0

Le premier chapitre du tutoriel est là !

J'aimerai vos avis sur ce premier chapitre d'une suite de tutoriels faits pour apprendre les bases du moteur, n'hésitez pas à corriger/retravailler certaines phrases (c'est l'intérêt du wiki) si vous pensez pouvoir l'améliorer :)

+10 -0

J'aime bien cette première partie, car elle touche plusieurs notions différentes. Ça me donne envie de m'y mettre et de tester un peu tout ça :) Une partie plus poussée sur l'installation et le build est prévue ? Car ça parait obvious pour une personne habituée, mais je pense que ça permettrait à plus de monde de mettre le pied à l'étrier ;-)

Encore merci, et franchement beau boulot.

J'aime bien cette première partie, car elle touche plusieurs notions différentes. Ça me donne envie de m'y mettre et de tester un peu tout ça :) Une partie plus poussée sur l'installation et le build est prévue ? Car ça parait obvious pour une personne habituée, mais je pense que ça permettrait à plus de monde de mettre le pied à l'étrier ;-)

Encore merci, et franchement beau boulot.

Thiphariel

C'est prévu, comme beaucoup de personnes me le réclament je vais écrire une introduction partant du téléchargement du moteur jusqu'à un premier exemple fonctionnel avec Code::Blocks et Visual Studio (et aussi comment utiliser Premake pour les autres :D ).

Merci de ton retour en tout cas !

+2 -0

De la folie ce projet. J'étais passé à côté, bien joué pour la mise à la une !

En plus c'est open source, j'suis tout fou :-) . Bon courage pour la suite @Lynix ! (ps moi OC j'ai tellement arrêté que j'avais pas vu ton topic là bas :p )

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte