Cette présentation est assez vieille et je n'ai pas encore eu le temps de la mettre à jour, je vous invite à venir page 48 pour la sortie de la version 0.1 et des précompilés !
Bonjour, Je m'appele Jérôme et j'ai 18 ans à l'heure où j'écris ces lignes. Je fais du C++ depuis presque quatre ans maintenant, j'ai également fait pendant quelques années du C, du PHP, du Lua, ainsi que touché au xHTML/CSS (Version 4), du Javascript, du SQL et du VB.
Il y a plus de deux ans j'ai entrepris la création de mon propre moteur dans un but pédagogique, et j'ai en effet beaucoup appris de cette expérience. Par la suite j'ai décidé de mener à terme ce moteur, malheureusement son architecture n'étant ni mature ni robuste et sa nomenclature me déplaisant de plus en plus, j'ai pris une décision il y a six mois. Celle de tout recommencer pour partir d'une bonne base.
Nazara n'est pas un changement de nom, il s'agit d'une réécriture complète de mon ancien moteur, les quelques rares fichiers repris ont étés révisés ligne par ligne, algorithme par algorithme.
Je suis donc assez fier de le présenter maintenant, Nazara dispose d'une architecture nettement plus solide, d'un code plus mûr et plus performant Aussi, une des différence majeure est que la licence est passée de LGPL à MIT (Presque du domaine libre)
Mon moteur est donc divisé en plusieurs bibliothèques organisées dans une certaine hiérarchie, chacune disposant de ses fonctionnalités et de ses prérequis.
À noter également qu'il est possible d'étendre Nazara en créant et en maintenant votre bibliothèque qui pourra peut-être se voir intégrée dans le projet. Par exemple, OveRdrivR est à l'origine de deux modules de Nazara.
Une dernière chose, Nazara est en C++, certes, mais en C++11. Cela signifie que pour compiler le moteur ou un projet l'utilisant, il vous faut un compilateur à jour (J'utilise la dernière version de GCC comme référence).
Le moteur est encore en développement intensif, mais passera bientôt en beta-test. Vous pouvez voir son avancement (Ainsi que ses capacités actuelles) ici à cette page (Attention déprécié).
Comme vous pouvez le voir sur la page des fonctionnalités, Nazara n'est pas encore tout à fait portable, car bien que son architecture le permette, je n'ai pas les connaissances des API Linux/Mac OS X. C'est pourquoi je suis à la recherche de personnes pouvant m'aider de ce côté Le noyau a déjà été adapté avec l'aide de Danman.
Le projet vous intéresse-t-il ? Car je cherche également des personnes pour tester le moteur une fois son entrée en beta-test, m'aider à développer l'interface (Voir ce qu'il manque, ce qu'il faut renommer/enlever, ...) et repérer les éventuels bugs
Il est juste nécessaire de connaître le C++ (Pas forcément le C++11) et d'avoir un compilateur supportant suffisamment la norme, je ne peux que vous conseiller GCC (>= 4.7) qui est mon compilateur
GCC à jour sur Windows (+ Utilisation avec CodeBlocks) Désolé, le lien est actuellement hors-service
Exemples de code pour illustrer la nomenclature :
#include <Nazara/Core/String.hpp>
NzString str = "Hello world !";
str.Replace("Hello", "Goodbye");
#include <Nazara/Renderer/Shader.hpp>
NzShader shader(nzShaderLanguage_GLSL);
if (!shader.LoadFromFile(nzShaderType_Fragment, "blur.frag"))
{
std::cout << "Failed to load fragment shader from file:" << std::endl;
std::cout << shader.GetLog() << std::endl;
return 1;
}
if (!shader.LoadFromFile(nzShaderType_Vertex, "blur.vert"))
{
std::cout << "Failed to load vertex shader from file:" << std::endl;
std::cout << shader.GetLog() << std::endl;
return 1;
}
if (!shader.Compile())
{
std::cout << "Failed to compile shader" << std::endl;
return 1;
}
Démos:
Première démo Une petite démo montrant l'affichage de meshs et d'animations (Réagi au clavier)
Vidéo de la seconde démo du moteur (House) présentant une scène plus aboutie (caméra FPS, multiples modèles et sources d'éclairages, intégration du son).
Je tire mon chapeau et je m'incline, c'est assez impressionnant de voir qu'il est possible de créer un moteur en amateur !
Pour la Beta-test il y a t-il des connaissances particulières a avoir (notamment en C++) ?
Je te donne tout mes encouragements pour la suite !
Pour la Beta-test il y a t-il des connaissances particulières a avoir (notamment en C++) ?
Non, Nazara n'est pas plus compliqué à utiliser que n'importe quelle bibliothèque, il est juste requis d'avoir un compilateur supportant suffisamment la norme (Ce n'est pas encore le cas de Visual Studio 2011), mais GCC pour Windows (MinGW) peut s'installer avec ce tuto.
J'ai rajouté des exemples de code ainsi qu'un lien vers le tutoriel
Tu devrais mettre le code dabs un espace de nom plustôt que de mettre le préfixe Nz parce que ça ralonge le code...
Y a-t-il un fichier d'entête qui va permettre de tout les inclures?¿?
J'ai hâte de le tester...
L'être humain, contrairement aux geeks qui ne sont de toute façon pas des êtres humains, est un animal social taillé pour vivre en "meute".
L'espace de nom est pire selon moi que deux petites lettres (Au passage, Nz:: ça fait quatre caractères :P)
Quant au using namespace, ça fait perdre toute leur utilité aux namespace, et les collisions avec des noms comme File ou String sont très probables.
Et puis, si on fait un using namespace avec la std en plus, on se retrouve avec string et String, je trouve ça moche personnellement.
Sans oublier l'argument sur l'auto-compétition
Pour toutes ces raisons j'ai opté pour un préfixe, après c'est une question de goûts
Pour le culling, je pense proposer :
-L'occlusion culling (Je lis un document sur le Coherent Hierarchical Culling actuellement)
-L'octree culling
-Le frustrum culling
Le but n'est pas d'utiliser les trois en même temps, mais de les proposer, et de laisser l'utilisateur choisir ce qu'il pense le plus adapté pour la scène
Pour revenir sur cette idée, j'avoue être personnellement plus favorable à un espace de nom qu'un préfixe, notamment parce que les espaces de nom sont une nouveauté assez plaisante visuellement.
Pour le nombre de caractères, using namespace Nz; est une possibilité de réduction du nombre de caractères utilisés !
Sinon, très bon projet, je vais suivre son évolution avec intérêt !
Les espaces de nom permettent aussi de bien diviser le code...
Ainsi, si tu créer un fichier d'entête qui inclu tous les autres, les personnes pourront savoir de quelle partie de ton moteur fait parti NzString et on pourra choisir d'utiliser ou pas les espace de nom.
En plus, cela permet de diminuer le nombre de fichier à inclure lorsque l'on utilise ton moteur...
L'être humain, contrairement aux geeks qui ne sont de toute façon pas des êtres humains, est un animal social taillé pour vivre en "meute".
Pour revenir sur cette idée, j'avoue être personnellement plus favorable à un espace de nom qu'un préfixe, notamment parce que les espaces de nom sont une nouveauté assez plaisante visuellement.
Pour le nombre de caractères, using namespace Nz; est une possibilité de réduction du nombre de caractères utilisés !
Sinon, très bon projet, je vais suivre son évolution avec intérêt !
Si le seul objectif des espace de noms est de les enlever, ils ne servent à rien, et si on le garde, alors ça fait pas mal de caractères en plus.
J'utilisais les espaces de noms avec l'Ungine et franchement je préfère un préfixe de deux lettres, c'est plus clair je trouve.
Chacun ses goûts, mais je doute que ça soit très gênant, on s'y fait vite
Citation : charlesfire
Les espaces de nom permettent aussi de bien diviser le code...
Ainsi, si tu créer un fichier d'entête qui inclu tous les autres, les personnes pourront savoir de quelle partie de ton moteur fait parti NzString et on pourra choisir d'utiliser ou pas les espace de nom.
En plus, cela permet de diminuer le nombre de fichier à inclure lorsque l'on utilise ton moteur...
Je trouve personnellement Nz::Core::String affreux comme manière d'écrire les choses, mais de toute façon l'utilisateur est censé savoir de quelle partie vient telle classe, il y a généralement peu d’ambiguïtés de ce côté.
Je n'ai pas compris par contre au niveau des fichiers à inclure, il est prévu de faire des includes "globaux" à la Qt (Qui utilise par ailleurs un préfixe) : #include <Nazara/Core.hpp>
Pour inclure tous les fichiers d'un module oui, comme je viens de le dire
Après un seul fichier pour inclure tous les modules ne sert à rien, si on a besoin de tous les modules dans un seul fichier c'est qu'on a, à mon avis, un problème d'architecture.
Il y a aussi quelques corrections au niveau du thread-safety, qui fonctionne correctement maintenant pour le noyau
Je travaille sur les images actuellement avec leur chargement, pour ensuite ajouter les textures et le chargement des meshs, pour enfin avoir un véritable rendu
Tous mes voeux de réussite,je suis justement dans un projet similaire actuellement,sans être un moteur de jeu,je créé un moteur 3D.Comme toi il y a deux ans,c'est dans un but pédagogique,et je rencontre souvent des difficultés qu'il faut surmonter,et cela permet d'apprendre énormément de choses.
(Il n'y a pas grand chose à faire, mais je n'ai aucune expérience là-dedans...)
Il y aurait quoi à faire précisément ? Connaître la libX et adapter ton code ?
Il faut gérer (Noyau):
-Dossiers et fichiers (Chemins Unicode et taille de 64bits)
-Threads, mutex, sémaphores (pthread, rien de bien compliqué)
-Les bibliothèques dynamiques
Je peux me charger des deux derniers, sans pouvoir tester
Il y a aussi le module Utility
-Xlib (Gestion de fenêtres, d'évenements et de modes vidéos)
Module Renderer:
-OpenGL (Gestion de contextes OpenGL, rien de bien compliqué )
Les implémentations système sont séparées en terme de fichiers du reste du moteur, il n'y a donc pas besoin de changer mon code (Mais tu peux reprendre l'implémentation windows pour t'inspirer)
Je trouve que c'est une super idée de vouloir faire de son moteur de jeu, un programme libre. J'ai moi aussi un moteur de jeu (opengl et donc multiplateforme) en construction, qui adopte cette même philosophie et aussi hébergé sur github, bien que je n'ai pas mis à jour mon git depuis deux mois. Personnellement je suis motivé par le fait qu'il faut que Windows ne soit pas la seule plateforme (pour ordinateur) dédiée aux jeux-vidéos.
Par contre je demandais ; tu as l'intention de supporter quel(s) formats de modèles 3D (COLLADA, OBJ, MD5, CAL3D, ...) ?
Sinon bon courage pour la suite. Je continuerai de suivre ce projet de près.
× 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.
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)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)