Il y aura un gestionnaire de ressource, une fois que l'interface aura été décidée.
Cependant, même lorsqu'il sera implémenté, l'utilisateur conservera le droit d'avoir la main libre sur la mémoire :
NzImage image;
if (!image.LoadFromFile("Logo.png"))
{
// Erreur
}
Il est possible de charger des textures depuis des fichiers, la mémoire ou un flux de données (Qui peut être n'importe quoi, même le réseau).
Dans le cas d'un fichier, le type est identifié par l'extension, dans les deux autres cas le moteur tente de déterminer le type du fichier grâce à son header
Je vais aussi faire des exemples d'utilisation du moteur avant de commencer les meshes, en attendant la doc, ça vous permettra déjà d'expérimenter le moteur et surtout de voir son interface.
Mais comme je suis en week-end (et de plus en examen), je ne risque pas de faire de commit avant lundi
Un petit commit de préparation, il déplace les buffers vers le module Utility afin de pouvoir par la suite charger des meshes et gérer plus facilement les Pixel buffer object (qui arrivent).
Le Renderer n'accepte plus de buffers software pour le rendu, car c'est déprécié depuis OpenGL 3 (et Nazara fonctionne avec le core profile).
Bref les prochains commits apporteront les meshes et les pixel buffer objects :-)
PS: Je suis désormais en vacances, j'ai réussi ma terminale
Ce qui signifie que mon travail sur Nazara va être plus fluctuant (Disons que j'aurais évidemment des cycles de travail correspondants à mes vacances ^^), avant ma reprise presque à temps plein en septembre sur le moteur
Un dernier commit avant que je ne parte en vacances, Nazara supporte maintenant les curseurs et icônes personnalisés.
Un précédent commit ajoutait le support pour les curseurs de l'OS, rendant possible l'utilisation des curseurs de l'interface de l'utilisateur dans Nazara.
Why so serious ? (Je sais, ce n'est pas le joker, mais il faudra s'en contenter pour le moment)
Je suis de retour ! (Au passage la Normandie c'est magnifique )
Je travaille d'arrache-pied sur les meshs, qui commencent à fonctionner comme en témoigne le screenshot plus haut. En effet Nazara peut maintenant charger les fichiers .md2 grâce au loader adapté de l'Ungine (C'est pratique de ne pas devoir tout réécrire ).
Je vous rassure, j'en ai un peu marre moi aussi de ce modèle low-poly Je compte me diriger vers le format md5 pour des modèles plus récents, et surtout animés de façon squelettique.
Car oui, l'interface a été décidée pour la gestion des animations squelettiques (et keyframe, la "vieille" méthode qui sera quand même supportée). Ainsi il sera facile de partager des animations entre plusieurs meshs, de charger des animations depuis un autre fichier comme depuis le fichier du modèle lui-même, etc...
Il ne manque pas grand chose pour animer le Dr. Freak comme dans l'Ungine, mais ça j'y réfléchirais demain
J'en ai aussi profité pour remanier une partie du moteur, notamment le ResourceManager qui est bien plus facile à utiliser.
Pour l'instant il y a 39 fichiers touchés par cette énorme modification. Les déclarations vont devoir être réécrites car elles ne conviennent plus au modèle actuel.
À noter que le moteur sera bientôt doté de petits projets démo d'exemple pour illustrer son utilisation
On se rapproche très fortement du stade où Nazara sera capable de faire tout ce que l'Ungine pouvait faire (Nazara fait bien plus en réalité déjà maintenant mais certaines fonctionnalités manquent encore à l'appel, comme le rendu sur image).
On se retrouve d'ici quelques jours pour de véritables animations
///FIXME: Améliorer les déclarations pour permettre de faire ça plus simplement
for (int i = 0; i < 12; ++i) // Solution temporaire, à virer
glDisableVertexAttribArray(i); // Chaque itération tue un chaton
Bien que je ne sois pas encore satisfait par l'architecture employée, les animations fonctionnent sans le moindre problème avec les modèles MD2.
Cela fait huit mois que Nazara existe, il aura fallu plus du triple à l'Ungine pour arriver à faire ça (Et Nazara fait bien plus de choses que l'Ungine dans beaucoup de domaines).
En vérité Nazara rattrapera très bientôt l'Ungine vis à vis de toutes ses fonctionnalités, les 12 démos de l'Ungine peuvent aujourd'hui être réécrites avec Nazara, mais je pense me diriger vers une autre façon de présenter tout cela.
Je mettrais en ligne une démo des animations dans les prochains jours, avec le code source afin de montrer comment s'utilise Nazara, ça ne vaut pas une documentation mais c'est déjà ça
Bref, actuellement je bute principalement sur des problèmes d'interface, rien de bien grave, je cherche simplement l'interface la plus robuste pour supporter les fonctionnalités futures
Salut ! Ton projet est super intéressant, vraiment ! De plus, si c'est un remake de l'Ungine (qui m'avait déjà impressionné à l'époque), tu ne fais pas qu'un moteur 3D, mais un moteur de jeu complet ! S'il se trouve qu'il est stable, performant, le fait de tout avoir sous la main pour créer un jeu complet pourrait franchement me décider à l'adopter à long terme !
Surtout qu'à voir comment tu en parles, tu parrais perfectionniste. Autant s'attendre à quelque chose de bien. Car même si ça prends plus de temps, ça peut vraiment valoir le coup.
Les animations squelettiques ne sont pas encore gérées mais le seront par la classe NzAnimation
// Copyright (C) 2012 Jérôme Leclercq
// This file is part of the "Nazara Engine".
// For conditions of distribution and use, see copyright notice in Config.hpp
#pragma once
#ifndef NAZARA_ANIMATION_HPP
#define NAZARA_ANIMATION_HPP
#include <Nazara/Prerequesites.hpp>
#include <Nazara/Core/String.hpp>
#include <Nazara/Utility/Enums.hpp>
#include <Nazara/Utility/Resource.hpp>
#include <Nazara/Utility/ResourceLoader.hpp>
#include <list>
#include <map>
struct NzAnimationParams
{
unsigned int endFrame = static_cast<unsigned int>(-1);
unsigned int startFrame = 0;
bool IsValid() const;
};
struct NzSequence
{
NzString name;
unsigned int firstFrame;
unsigned int lastFrame;
unsigned int framePerSecond;
};
class NzAnimation;
typedef NzResourceLoader<NzAnimation, NzAnimationParams> NzAnimationLoader;
struct NzAnimationImpl;
class NAZARA_API NzAnimation : public NzResource
{
friend class NzResourceLoader<NzAnimation, NzAnimationParams>;
public:
NzAnimation() = default;
~NzAnimation();
unsigned int AddSequence(const NzSequence& sequence);
bool Create(nzAnimationType type, unsigned int frameCount);
void Destroy();
unsigned int GetFrameCount() const;
NzSequence* GetSequence(const NzString& sequenceName);
NzSequence* GetSequence(unsigned int index);
const NzSequence* GetSequence(const NzString& sequenceName) const;
const NzSequence* GetSequence(unsigned int index) const;
unsigned int GetSequenceCount() const;
nzAnimationType GetType() const;
bool HasSequence(const NzString& sequenceName) const;
bool HasSequence(unsigned int index = 0) const;
bool IsValid() const;
bool LoadFromFile(const NzString& filePath, const NzAnimationParams& params = NzAnimationParams());
bool LoadFromMemory(const void* data, std::size_t size, const NzAnimationParams& params = NzAnimationParams());
bool LoadFromStream(NzInputStream& stream, const NzAnimationParams& params = NzAnimationParams());
void RemoveSequence(const NzString& sequenceName);
void RemoveSequence(unsigned int index);
private:
NzAnimationImpl* m_impl = nullptr;
static std::list<NzAnimationLoader::MemoryLoader> s_memoryLoaders;
static std::list<NzAnimationLoader::StreamLoader> s_streamLoaders;
static std::multimap<NzString, NzAnimationLoader::LoadFileFunction> s_fileLoaders;
};
#endif // NAZARA_ANIMATION_HPP
Mesh.hpp
// Copyright (C) 2012 Jérôme Leclercq
// This file is part of the "Nazara Engine".
// For conditions of distribution and use, see copyright notice in Config.hpp
#pragma once
#ifndef NAZARA_MESH_HPP
#define NAZARA_MESH_HPP
#include <Nazara/Prerequesites.hpp>
#include <Nazara/Core/InputStream.hpp>
#include <Nazara/Core/String.hpp>
#include <Nazara/Utility/Animation.hpp>
#include <Nazara/Utility/ResourceLoader.hpp>
#include <Nazara/Utility/Resource.hpp>
#include <list>
#include <map>
class NzSubMesh;
class NzVertexDeclaration;
struct NzMeshParams
{
NzAnimationParams animation;
//const NzVertexDeclaration* declaration = nullptr;
bool forceSoftware = false;
bool loadAnimations = true;
bool IsValid() const;
};
class NzMesh;
typedef NzResourceLoader<NzMesh, NzMeshParams> NzMeshLoader;
struct NzMeshImpl;
class NAZARA_API NzMesh : public NzResource
{
friend class NzResourceLoader<NzMesh, NzMeshParams>;
public:
NzMesh() = default;
~NzMesh();
unsigned int AddSkin(const NzString& skin, bool setDefault = false);
nzUInt8 AddSubMesh(NzSubMesh* subMesh);
nzUInt8 AddSubMesh(const NzString& identifier, NzSubMesh* subMesh);
void Animate(unsigned int frameA, unsigned int frameB, float interpolation);
bool Create(nzAnimationType type);
void Destroy();
const NzAnimation* GetAnimation() const;
nzAnimationType GetAnimationType() const;
unsigned int GetFrameCount() const;
NzString GetSkin(unsigned int index = 0) const;
unsigned int GetSkinCount() const;
NzSubMesh* GetSubMesh(const NzString& identifier);
NzSubMesh* GetSubMesh(nzUInt8 index);
const NzSubMesh* GetSubMesh(const NzString& identifier) const;
const NzSubMesh* GetSubMesh(nzUInt8 index) const;
nzUInt8 GetSubMeshCount() const;
unsigned int GetVertexCount() const;
bool HasAnimation() const;
bool HasSkin(unsigned int index = 0) const;
bool HasSubMesh(const NzString& identifier) const;
bool HasSubMesh(nzUInt8 index = 0) const;
bool IsAnimable() const;
bool IsValid() const;
bool LoadFromFile(const NzString& filePath, const NzMeshParams& params = NzMeshParams());
bool LoadFromMemory(const void* data, std::size_t size, const NzMeshParams& params = NzMeshParams());
bool LoadFromStream(NzInputStream& stream, const NzMeshParams& params = NzMeshParams());
void RemoveSkin(unsigned int index = 0);
void RemoveSubMesh(const NzString& identifier);
void RemoveSubMesh(nzUInt8 index = 0);
bool SetAnimation(const NzAnimation* animation);
private:
NzMeshImpl* m_impl = nullptr;
static std::list<NzMeshLoader::MemoryLoader> s_memoryLoaders;
static std::list<NzMeshLoader::StreamLoader> s_streamLoaders;
static std::multimap<NzString, NzMeshLoader::LoadFileFunction> s_fileLoaders;
};
#endif // NAZARA_MESH_HPP
Cet énorme commit sera en ligne dans les prochains jours, avec un code d'exemple permettant de jouer avec Dr. Freak, ou bien un autre personnage plus obscur ...
La question du namespace a déjà été traitée dans les pages précédentes.
Je ne dis pas que je ne changerais jamais d'avis, mais les arguments que j'ai eu jusqu'ici ne m'ont pas convaincus, à savoir :
-Ça permet d'utiliser using namespace: Je suis convaincu qu'il s'agit d'une mauvaise pratique de programmeur que d'utiliser d'abuser d'usingnamespace, à quoi bon utiliser un namespace si c'est pour l'enlever ?
-Le préfixe rallonge le code: Un namespace "Nz" fait quatre caractères "Nz::Window", contre deux pour un préfixe "NzWindow"
-Ça fait C: Je ne trouve pas, et puis Qt est bien en C++
-Les namespaces sont plus beaux: Il s'agit d'une question de goût, comparons deux petits codes :
Je suis mitigé, j'apprécie les deux nomenclatures.
C'est peut-être bien le seul argument qui me ferait changer d'avis.
Le préfixe est plus court, original.
Le namespace laisse le choix quant à son utilisation (Bien que je sois contre cette pratique), est légèrement plus long, mais bien plus répandu.
Nazara n'étant même pas encore en beta, il est donc encore possible de changer cela.
J'aimerais juste un retour utilisateur, quelle nomenclature préférez-vous ?
Le namespace est avant tout là par précaution, mais l'enlever (la plupart du temps) rend le code moins explicite, c'est pourquoi je soutiens le choix du préfixe.
Je soutiens le choix du préfixe pour des raisons esthétiques et de compacité.
Pour revenir à l'avancement du projet que compte tu faire maintenant : développer des démos techniques ou bien continuer d'ajouter des fonctionnalités au moteur?
La question du namespace a déjà été traitée dans les pages précédentes.
Je ne dis pas que je ne changerais jamais d'avis, mais les arguments que j'ai eu jusqu'ici ne m'ont pas convaincus, à savoir :
a -Ça permet d'utiliser using namespace: Je suis convaincu qu'il s'agit d'une mauvaise pratique de programmeur que d'utiliser d'abuser d'usingnamespace, à quoi bon utiliser un namespace si c'est pour l'enlever ?
b -Le préfixe rallonge le code: Un namespace "Nz" fait quatre caractères "Nz::Window", contre deux pour un préfixe "NzWindow"
c -Ça fait C: Je ne trouve pas, et puis Qt est bien en C++
d -Les namespaces sont plus beaux: Il s'agit d'une question de goût, comparons deux petits codes :
[...]
Je suis mitigé, j'apprécie les deux nomenclatures.
C'est peut-être bien le seul argument qui me ferait changer d'avis.
Le préfixe est plus court, original.
Le namespace laisse le choix quant à son utilisation (Bien que je sois contre cette pratique), est légèrement plus long, mais bien plus répandu.
Nazara n'étant même pas encore en beta, il est donc encore possible de changer cela.
J'aimerais juste un retour utilisateur, quelle nomenclature préférez-vous ?
Je vais répondre dans l'ordre :
a) tu as tout à fait raison sur ce point, j'exècre le mot-clé using.
b) il faut voir que dans bien des cas cela raccourcit en fait . Puisque la (quasi ?) totalité des IDE (je suis sous c::b perso) implémente un outils de code-complétion, au moment ou l'on tape :: on obtient la liste des classes du namespace nz et seulement elles. Ce qui est très appréciable si on ne veut pas fouiller la doc parce qu'on a oublié le nom exact d'une classe (avec majuscules, minuscule et tout le bataclan). Je te déconseille de choisir un nom de namespace avec majuscule par contre. nz est plus fonctionnel que Nz.
c) Qt n'est pas considéré comme du C++ (il n'utilise même pas le standard 98, alors pour adapter à du 11 vous pouvez vous gratter).
d) si, avec une coloration syntaxique, les :: sont mis en relief pour montrer qu'on utilise des classes issues d'une librairie (en l'occurrence Nazara), et non des classes de notre propre cru.
Germino, pour l'auto-completion les IDE gèrent aussi les mots commençant par une certaine séquence de lettres... Dans l'exemple de Qt, taper QS... sortira QString, QSize, QScreen, etc.
Comme je ne connais pas beaucoup de mots qui commencent par "Nz", ça ne devrait pas poser de problèmes.
Personnellement, je suis pour l'utilisation des namespaces à condition que tout ne soit pas dans le même. Par exemple, dans le code que tu nous montre Les Mesh, les Animation et les Window sont tous dans le même namespace (je suppose que les String, les List aussi?).
En revanche, un namespace Nz dans lequel tu inclus d'autres namespaces (core, video, noise, network...), à la manière de irrlicht ou de sfml, ça c'est intelligent et ça permet d'avoir chaque namespace dédié à une lib de ton moteur.
PS: je taff' sur une lib réseau basée sur winsock en ce moment, elle est assez fonctionnelle (TCP/UDP + synchrone/Asynchrone + sérialisation/désérialisation), si ça t'intéresse PM moi
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
Et pourquoi pas un namespace NazaraEngine::RenderEngine::Core::Beta::Screen tant qu'on y est? Rajouter des namespaces pour chaque module est complètement inutile et contre-productif.
Et pourquoi pas un namespace NazaraEngine::RenderEngine::Core::Beta::Screen tant qu'on y est? Rajouter des namespaces pour chaque module est complètement inutile et contre-productif.
Faut pas abuser non plus, ni me faire dire ce que j'ai pas dit.
Mais un découpage:
namespace Nz {
namespace core;
namespace video;
namespace net;
namespace phys;
namespace noise;
namespace audio;
...
}
est censé. Au moins tu colles chaque classe dans le namespace qui lui correspond. En plus, Lynix a lui même mis sur son site l'avancement des différents modules: il a déjà fait le découpage!
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
Il est absolument hors de question que je sépare chaque classe dans un namespace associé à son module, qui à envie d'utiliser une bibliothèque dont les chaînes de caractères s'appellent Nz::Core::String par exemple ?
Je ne dis pas que ce choix n'est pas censé, au contraire, mais c'est tout bonnement horrible à utiliser
Les classes sont séparées dans les modules au niveau des headers pour que l'utilisateur soit conscient des dépendances et des modules à initialiser pour que cette même classe fonctionne.
Nazara n'est pas une bibliothèque mais un ensemble de bibliothèques
Quant aux collisions au niveau des noms, je préfère tout laisser dans un espace global et ajouter des précisions sur le nom quand nécessaire (Exemple, une entité physique s'appellera NzPhysObject plutôt que NzObject)
J'ai pris en compte vos avis mais après réflexion je garde le préfixe
De toute façon, ça n'a pas grande importance
Citation : charlesfire
Prévois-tu faire ton propre moteur physique ou intégrer un moteur déjà existant comme Bullet ou PhysX?¿?
Je compte utiliser un moteur existant, pour l'instant mon choix se porte sur Newton Game Dynamics mais il faut également voir les autres
Citation : LethalParadox
Pour revenir à l'avancement du projet que compte tu faire maintenant : développer des démos techniques ou bien continuer d'ajouter des fonctionnalités au moteur?
Je vais sortir le commit sur les meshes/animations avec une petite démo :-)
× 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)
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
"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)