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.
@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...
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).
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
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
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
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 !
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
Ç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
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.
Ç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
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
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
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à
× 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)