Merci !

Pour les formats que je compte supporter, Nazara adopte un format extensible (Capacité de rajouter des formats par plugin), mais de base je pense gérer en tout cas l'OBJ, le MD2, MD5, le MD3 si j'arrive à intégrer ses trois modèles dans l'architecture, le collada.

Je pense notamment gérer mon propre format

Et bien sûr en rajouter d'autres par la suite

Tu rajoutera les fichiers .blend ?

@WSJ : Importer ce genre de fichier c'est pas bon. C'est très lourd à charger. Il y a plein d'informations inutiles. Encore beaucoup plus que le collada déjà que c'est surchargé et écrit en XML. De plus, c'est un format compliqué car non codé en ASCII. Et puis, c'est pour gérer des scènes et non des meshes. Ce sont pas les arguments qui manquent...

Bah a quoi sert blender alors ?

Si Lynix crée son propre format, on verra peut-être pour créer un plugin blender qui se charge de l'export d'objets.

Il faudrait pouvoir charger des scènes...
Ton format le supportera-t-il???

Citation

Il faudrait pouvoir charger des scènes...

Je ne vois pas pourquoi. Blender n'est pas un éditeur de map, c'est possible mais pas fait pour ça.

De toute façon le jour où le problème des maps se posera n'est pas encore arrivé, et des outils haut-niveau seront développés à ce moment.

Non je ne compte pas supporter les fichiers de blender, maya, 3DS ou autre, ils sont tous dotés d'exporteurs créés notamment pour les moteurs de jeux.

Je ne prévois pas directement la gestion de scène, d'entité ou de gameplay dans Nazara, qui au contraire du source engine par exemple, ne se mêlera pas des choix de l'utilisateur quant à l'organisation de son programme (Ce qui lui demandera plus de travail, mais également plus de liberté).

En revanche je prévois une surcouche au moteur entier, pour justement s'occuper de ces points là, et permettre le développement de jeux vidéos assez aisément.

Nouveau commit, ajoutant le support des mipmaps à NzImage et corrigeant les erreurs de la conversion de pixels (Support du boutisme notamment).

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

C'est très probablement le dernier commit avant le support des textures dans le module OpenGL, je les ai déjà testées dans mon programme d'essai et elles fonctionnent bien.

Petite précision, NzImage va encore supporter des "filtres", ou plutôt des "effets" exécutés sur l'image, permettant de changer la taille, d'effectuer une rotation, de générer toutes les mipmaps, etc ...

Côté formats de pixels, je dois encore rajouter la décompression software (DXT* -> RGBA par exemple), ainsi que la compression bien évidemment, mais je crains de n'avoir un problème de licence vis à vis de la compression DXT, personne n'aurait d'informations à ce sujet ?

Petit up pour vous informer qu'un gros bug du moteur empêchant le rendu avec certaines cartes graphiques récentes vient d'être résolu par le support des VAOs (Vertex Array Objects)

Cela va par ailleurs augmenter légèrement les performances du rendu.

Les textures fonctionnent de mon côté, je dois encore leur faire une bonne interface et ensuite je pourrais commiter, disons demain ou après-demain

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

Juste pour suivre :-)

Bon courage !

(utopia est-il toujours d'actualité (à très long terme) ou est-il mort ?)

Utopia est toujours d'actualité et à cours terme

Oui je n'avais pas encore regardé le sujet dédié... Scuse.

En tout cas, c'est cool !

Voilà, les textures sont intégrées à Nazara

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

Prochaine étape, le rendu sur texture, le "screenshot" (Création d'une texture avec le contenu d'une fenêtre de rendu).

Après ça, chargement des meshs, pour évidemment les afficher, début du moteur 2D et du moteur 3D

Est-ce que ton moteur 3d proposera un rendu par voxels?¿?
Créra-tu ton propre format de scène, comme les fichier *.irr de irrlicht?¿?

Qu'est-ce qu'un rendu par voxels sinon une architecture de scène qui finit par rendre des triangles ?

Il est encore tôt pour parler des scènes, car il ne s'agit plus du même projet mais d'une surcouche de Nazara, ce dernier étant un moteur de jeu et non pas un SDK

Nazara se dote d'un nouveau module, le module Noise pour la gestion des bruits, écrit par OveRdrivR. Je vais faire en sorte de mettre à jour la liste des capacités de Nazara pour rajouter ce module aujourd'hui si possible.
Je vous invite à regarder du côté du topic de ZNoise : http://www.siteduzero.com/forum-83-722 [...] eatoires.html

Le commit sur le RTT (Rendu sur texture) avance, avec certaines difficultés liées aux FBOs d'OpenGL (Notamment le fait qu'ils ne soient pas partageables entre contextes, au contraire du reste).

Après ça, gestion des meshes, le plus difficile va être de gérer les animations au niveau de l'interface, mais je vous tiens au courant

Salut ! Pour te dire que je trouve ton projet très intéressant
(bien pour le C++11)

Je trouve moi aussi ce projet très intéressant !
Je suis intéressé pour les tests, mais seulement sous linux (si tu trouve un développeur...)
Et bonne continuation !

Merci pour vos commentaires

J'ai divisé le commit sur render texture en plusieurs parties car il devenait trop gros (Même là il est beaucoup trop gros pour un seul commit) et long à venir.

Voici donc un gros commit qui corrige des bugs, renomme certaines fonctions, optimise le moteur, et ajoute quelques petites fonctionnalités (gestion des cubes).

J'espère bientôt sortir les render texture pour vite passer aux meshes

https://github.com/DigitalPulseSoftwar [...] 5cba4c8eb45c2

Vraiment bravo ! Je suis très impressionné par ton travail, je vais suivre ton avancé avec beaucoup d’intérêt !

Ça ressemble beaucoup à la SFML au niveau de l'architecture des classes et même de leurs méthodes ! On y trouve les mêmes classes du style nzVideoMode <=> sf::VideoMode, nzRenderWindow <=> sf::RenderWindow, nzNonCopyable <=> sf::NonCopyable !

Bah, en même temps, un mode vidéo, c'est un mode vidéo, une fenêtre de rendu, c'est une fenêtre de rendu, et une classe non copiable, c'est une classe non copiable, pourquoi faire de l'obfuscation en utilisant des noms différents? oO'

Bonjour,
Pour compiler sous MinGW, j'ai du :
remplacer _stdcall par __stdcall dans Core/Win32/ThreadImpl
Ajouter --std=c++11 dans les options de compilation

Ajouter
#define OEMRESOURCE
avant
#include <windows.h>
et

#ifdef _WIN64
#define GWL_USERDATA GWLP_USERDATA
#define GCL_HCURSOR GCLP_HCURSOR
#endif

après (le include) dans Utility/Win32/WindowImpl
Et renommer std_image.c en stb_image.cpp, sinon j'avais une erreur indiquant que premake essayait d'utiliser le compilateur de Microsoft pour les fichiers C.

Sinon, c'est bien, mais il n'y a pas d'exemples.

Citation : metayd1

Ça ressemble beaucoup à la SFML au niveau de l'architecture des classes et même de leurs méthodes ! On y trouve les mêmes classes du style nzVideoMode <=> sf::VideoMode, nzRenderWindow <=> sf::RenderWindow, nzNonCopyable <=> sf::NonCopyable !

Le fenêtrage est inspiré de l'interface de la SFML, simplement parce que je trouve que c'est une interface très efficace, mais si je trouve mieux un jour, ça changera probablement.

Citation : RafBill

Bonjour,
Pour compiler sous MinGW, j'ai du :
remplacer _stdcall par __stdcall dans Core/Win32/ThreadImpl
Ajouter --std=c++11 dans les options de compilation

Ajouter
#define OEMRESOURCE
avant
#include <windows.h>
et

#ifdef _WIN64
#define GWL_USERDATA GWLP_USERDATA
#define GCL_HCURSOR GCLP_HCURSOR
#endif

après (le include) dans Utility/Win32/WindowImpl
Et renommer std_image.c en stb_image.cpp, sinon j'avais une erreur indiquant que premake essayait d'utiliser le compilateur de Microsoft pour les fichiers C.

Sinon, c'est bien, mais il n'y a pas d'exemples.

En effet, merci pour le feedback ! Je suppose que tu utilises MinGW-64 ?

J'ai corrigé ça pour le prochain commit
Excepté pour le "--std=c++11" parce que premake ne me permet pas de le préciser.

Pour les exemples, ils vont venir dans un prochain commit, je travaille justement sur une démo utilisant le module Noise

Merci beaucoup à toi

Citation : Gigotdarnaud

Bah, en même temps, un mode vidéo, c'est un mode vidéo, une fenêtre de rendu, c'est une fenêtre de rendu, et une classe non copiable, c'est une classe non copiable, pourquoi faire de l'obfuscation en utilisant des noms différents? oO'

Nan, c'est sûr, mais bon là y'a une ressemblance flagrante, en particulier au niveau du nom des méthodes : Display, UseVerticalSync, enfin je suis d'accord que c'est logique qu'il y ai des méthodes qui se ressemblent dans chaque lib graphique (logique) mais on sent quand même une grosse influence de SFML, je ne fais que constater

Citation : Lynix

J'ai corrigé ça pour le prochain commit
Excepté pour le "--std=c++11" parce que premake ne me permet pas de le préciser.

J'avais rajouté buildoptions "--std=c++11" dans common.lua. Avec un if gcc then, ca devrait passer, non ?

Le problème c'est de détecter GCC avec premake, ce n'est pas une mince affaire :/

Au passage, je viens de voir que MinGW avait été mis à jour, je vais activer toutes les fonctionnalités C++11 apparue dans GCC 4.7

La longueur d'un vecteur à coords entières peut ne pas être entière : (1;1) -> racine de 2

Et pour premake, je pense que le générateur gmake suppose GCC, donc un configuration "gmake" buildoptions "--std=c++11" devrait marcher, non ?
Et pour les fonctionalités C++11, beaucoup ne sont pas supportées par MSVC (template aliases, ...)

En effet, et malheureusement le support pour Visual attendra que le compilateur supporte ces options (Mais la RC 2012 fait déjà un grand pas en avant )

C'est ennuyeux pour les vecteurs, je suppose qu'une spécialisation suffirait .. Je vais regarder ça de plus près

Depuis GCC 4.7, les fenêtres threadées ne fonctionnent plus correctement, je ne comprends pas le problème..

Enfin bon, je sens que les RenderTexture vont attendre, je pense me concentrer assez vite sur les meshes pour pouvoir afficher quelque chose d'intéressant (Le RTT sert pour des effets bien plus évolués qu'actuellement, comme les reflets dynamiques ou le deferred shading..).

Le format de référence pour l'animation squelettique sera le MD5, pour l'animation key-frame, ce sera le MD2

Nazara supportera bien d'autres formats bien sûr, mais je vais commencer par ces deux-là

Le moteur intègre un gestionnaire de ressources ou on a la main libre sur la mémoire ?