Partage

[Moteur de jeu] Nazara Engine

Moteur de jeu en développement

14 juin 2012 à 20:29:17

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 :)
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
14 juin 2012 à 20:46:47

Cool, je déteste quand un moteur essaie de cacher la gestion mémoire :)
15 juin 2012 à 11:22:40

Moi aussi, c'est d'ailleurs une des raisons qui fait que j'ai fait mon propre moteur plutôt que d'utiliser celui d'un autre.

Je viens de push un gros commit, il corrige beaucoup de bugs dans NzImage et NzTexture, qui normalement ne contiennent plus de bug.

https://github.com/DigitalPulseSoftwar [...] f20f76ebce1c2

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 :)

Bon week-end ;)
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
21 juin 2012 à 9:59:53

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 :-)

https://github.com/DigitalPulseSoftwar [...] 956df2ecaaf4c

PS: Je suis désormais en vacances, j'ai réussi ma terminale :D

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 :)
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
24 juin 2012 à 13:33:20

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.

https://github.com/DigitalPulseSoftwar [...] 9f26d72212de9
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
3 juillet 2012 à 1:05:18

Image utilisateur
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 :p ).

Je vous rassure, j'en ai un peu marre moi aussi de ce modèle low-poly :lol: 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 ;)

-
Edité par Lynix 27 octobre 2015 à 22:37:56

Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
3 juillet 2012 à 12:57:30

Comptes-tu gérer un système de GUI ?
3 juillet 2012 à 16:21:43

C'est une idée en effet, je pensais utiliser Gwen, donc dans un premier temps, simplement proposer un Renderer compatible :-)
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
Anonyme
4 juillet 2012 à 1:12:19

J'espere que t'as amélioré ça dans Renderer.cpp

///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 


sale tueur de chats.
4 juillet 2012 à 11:32:10

C'est justement ce qui va (enfin) partir avec la réécriture des vertex declaration :)
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
5 juillet 2012 à 15:38:25

Citation

Je suis de retour !
(Au passage la Normandie c'est magnifique ;) )


<hs>Ah, tu es venu dans ma région :D
J'espere que tu es tombé sur les 2-3 jours ou il n'a y pas eu de pluie....</h>

J'ai hâte d'essayer la démo pour voir comment utiliser Nazara :)
Quel est le cri d'un canard quantique ? Quark Quark. Quel est le cri d'un ornithorynque quantique ?
6 juillet 2012 à 23:11:33

Les animations fonctionnent ! :D

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 :)

À suivre ^^
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
7 juillet 2012 à 11:48:30

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. :)
7 juillet 2012 à 17:10:58

Je suis d'accord
Vous voulez créer des jeux-vidéos en C/C++ ? Vous aimez regarder des gameplays ? Visitez ma chaîne YouTube ;) 
8 juillet 2012 à 15:27:04

Et voilà, l'interface des meshs et animations est décidée et implémentée.

Les animations fonctionnent donc sans le moindre souci :)

Voici un exemple de code :
NzMesh mesh;
if (!mesh.LoadFromFile("drfreak.md2"))
{
	std::cout << "Failed to load mesh" << std::endl;
	return 1;
}

const NzAnimation* animation = mesh.GetAnimation();
cont NzSequence* sequence = animation->GetSequence("stand");
// La séquence indique comment jouer l'animation


Pour les curieux voici les headers :)
Animation.hpp

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 ... :o^^
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
9 juillet 2012 à 14:11:59

Salut !
J'aurais juste une remarque à formuler :
un namespace nz aurait été beaucoup plus approprié que la nomenclature à la C...
9 juillet 2012 à 14:32:06

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'using namespace, à 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 :

Actuel
NzMesh mesh;
if (!mesh.LoadFromFile("drfreak.md2"))
{
	std::cout << "Failed to load mesh" << std::endl;
	return 1;
}

const NzAnimation* animation = mesh.GetAnimation();
cont NzSequence* sequence = animation->GetSequence("stand");
// La séquence indique comment jouer l'animation


NzRenderWindow window(NzVideoMode(800, 600, 32), "Nazara Window", nzWindowStyle_Default, NzRenderTargetParameters(8));


Avec namespace
Nz::Mesh mesh;
if (!mesh.LoadFromFile("drfreak.md2"))
{
	std::cout << "Failed to load mesh" << std::endl;
	return 1;
}

const Nz::Animation* animation = mesh.GetAnimation();
cont Nz::Sequence* sequence = animation->GetSequence("stand");
// La séquence indique comment jouer l'animation


Nz::RenderWindow window(Nz::VideoMode(800, 600, 32), "Nazara Window", Nz::WindowStyle_Default, Nz::RenderTargetParameters(8));


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 ?
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
9 juillet 2012 à 14:35:22

Le namespace est plus dans la "norme" à mon avis, mais j'aime vraiment bien le préfixe à la Qt en effet.
9 juillet 2012 à 14:49:16

Moi, je préfère le namespace comme sfml...
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".
9 juillet 2012 à 15:03:59

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.
9 juillet 2012 à 15:25:54

Bonjour,

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?
9 juillet 2012 à 15:31:44

Prévois-tu faire ton propre moteur physique ou intégrer un moteur déjà existant comme Bullet ou PhysX?¿?
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".
9 juillet 2012 à 15:38:44

Citation : Lynix

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'using namespace, à 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.

voilà, j'espère avoir été clair dans ma réponse ^^ .
9 juillet 2012 à 16:48:36

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.
9 juillet 2012 à 16:58:51

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."
9 juillet 2012 à 17:31:51

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.
9 juillet 2012 à 17:41:58

Citation : Gigodarnaud

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."
9 juillet 2012 à 20:19:00

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 o_O

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 :-)
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
10 juillet 2012 à 18:35:28



Voici la première démo de Nazara, pour fêter sa présentation dans le récap communautaire venant de sortir :)

Le code source est assez crade, il n'est donc pas inclus, cette démo ressortira comme un exemple avec le commit avec le code source inclus (et épuré :D )
Nazara Engine | Discord NaN ! (Chat dédié à la programmation) | Ma chaîne Twitch (développement)
10 juillet 2012 à 18:46:26

il manquerait pas un getchar() à la fin du programme des fois :-° ?

[Moteur de jeu] Nazara Engine

× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
  • Editeur
  • Markdown