alut, en fait, j'ai fais une classe qui récupère les constructeurs d'une classe créée par l'utilisateur, et une gui qui me permet de créer un objet de cette classe.
Ensuite, l'application créée un script qu'il compile et exécute pour créer les objets et les ajouter dans l'application et les sauvegarder dans une fichier, voici le script en question :
Lorsque je ne crée qu'un seul objet pnj, ça passe, mais lorsque je veux en créer deux, ça plante, pourtant, j'ai bien fait un test sur la taille du vecteur pour ne pas réallouer le premier objet pnj lorsque je crée le deuxième et il ne va pas dans la méthode addExternal pour le premier objet lorsque je crée le deuxième mais rien à faire, ça plante comme si il y avait un accès concurrent ou bien que le premier objet pnj a été réalloué, pourtant l'application attend bien que la fonction du .so aie fini de s'exécuter avant de continuer donc il ne devrait pas y avoir d'accès concurrent.
EDIT : Bon j'ai trouvé la solution, en fait, le problème c'est que lorsque je recompile le .so, comme j'ai alloué l'entité pnj dans le .so on dirait que à la recompilation du .so le premier object pnj n'est plus valide alors j'ai créer un vecteur temporaire dans lequel je stocke les entités à ajouté à partir de la dll :
void ODFAEGCreator::addExternalEntity(Entity* entity, std::string type) {
//std::cout<<"add entity : "<<entity<<std::endl;
/*Command::sname = "EXTERNAL";
name = "EXTERNAL";*/
/*entity->setExternal(true);
selectedObject=entity;
displayTransformInfos(entity);
displayEntityInfos(entity);
getWorld()->addEntity(entity);*/
std::map<std::string, std::vector<Entity*>>::iterator it = toAdd.find(type);
if (it == toAdd.end()) {
toAdd.insert(std::make_pair(type, std::vector<Entity*>()));
it = toAdd.find(type);
}
it->second.push_back(entity);
}
Pour les cloner et les ajouter plus tard avec l'application :
void ODFAEGCreator::onExec() {
std::map<std::string, std::vector<Entity*>>::iterator it;
std::map<std::string, std::vector<Entity*>>::iterator it2;
for (it = toAdd.begin(); it != toAdd.end(); it++) {
it2 = externals.find(it->first);
if (it2 == externals.end()) {
externals.insert(std::make_pair(it->first, std::vector<Entity*>()));
it2 = externals.find(it->first);
}
for (unsigned int i = 0; i < it->second.size(); i++) {
Entity* entity = it->second[i]->clone();
entity->setExternal(true);
if (i == it->second.size()-1) {
selectedObject=entity;
displayTransformInfos(entity);
displayEntityInfos(entity);
getWorld()->addEntity(entity);
it2->second.push_back(entity);
}
delete it->second[i];
}
}
toAdd.clear();
>ça plante comme si il y avait un accès concurrent
Toujours avec vos boucs émissaires pour pas cher.
Bon, ces chemins à la con dans les "#include", vous comptez les utiliser encore longtemps ?
Comme je l'ai déjà dit, le manque d'ABI en C++ fait que votre approche n'est qu'un horrible bricolage, et les "new" fait dans une Dll qui va se faire recycler, ça me laisse rêveur (l'application n'a pas forcement la même C-Runtime que la dll et la nouvelle version de la Dll n'a même pas forcement la même définition de la classe, c'est donc bien la mer..).
Tant d'efforts pour un truc qui ne fonctionnera quasiment jamais dans le monde de la vraie vie véritable, c'est triste.
C'est beau la confiance que vous avez de la classe "odfaeg::core::OTextArchive" pour qu'elle gère correctement les champs de types pointeurs, sans support de la réflexion nativement en C++. Moi, je suis plus suspicieux et je regarderais le contenu du fichier "Pnj.oc" pour voir s'il n'y colle pas des pointeurs bien foireux.
Vous êtes bien gentil avec votre copie d'écran avec un "watch" de variable, mais avec la ligne ou ça plante, c'est quand même bien plus pratique, ainsi que le texte complet du message d'erreur/d'exception.
P.S.: Arrêtez d'utiliser le terme script pour du code C++, et pour du code de tout langage compilé, ce ne sont pas des scripts (et c'est bien pour cela que votre approche est foireuse).
P.S.S.: C'est couillu d'utiliser une variable globale (vPnj) quand on vous a déjà indiqué que les variables statiques, c'est comme les variables globales, c'est un piège à con.(mais bon ici, c'est peut-être un cas "justifié")
EDIT :
>on dirait que à la recompilation du .so le premier object pnj n'est plus valide
Bin forcement, quand vous déchargez une Dll, c'est aussi bien le code que son ou ses segments de données.
Quand vous rechargez la Dll, elle n'est même pas obligée d'être rechargée avec les même adresse.
Je pensais que votre fichier d'objet sérialisée : "Pnj.oc", servait justement à conserver ces données entre le déchargement et le rechargement.
Et remerciez le fait de n'avoir qu'un heap (un seul runtime-C) pour que votre hack ne se casse pas la gueule.
- Edité par bacelar 14 janvier 2021 à 3:44:45
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Je plussoie. À force de faire trop de généricité et d'overengineering on perd en simplicité et stabilité. Le C++ n'est pas un langage de script c'est un langage statique et compilé.
Si ton but est de « charger » des objets dynamiques pour ton jeu alors un langage de script est plus adapté. Sinon en C++, code tout simplement tes entités directement dans ton application. Les charger dynamiquement n'a absolument aucun bénéfice.
- Edité par markand 14 janvier 2021 à 15:54:09
git is great because Linus did it, mercurial is better because he didn't.
Pourquoi alloues donc tu la mémoire manuellement avec new/delete au lieu d'utiliser std::make_unique et un std::unique_ptr ?
Bonjour, comme je crée l'entité avec le .so et que je le delete dans l'application, il faudrait que j'utilise des std::move je pense pas que ça serait plus simple de faire comme ça.
dragonjoker a écrit:
Franchement, il vaudrait mieux utiliser un vrai langage de script...
Je ne connais pas de langage de script et je ne sais pas si il est possible d'exécuter une fonction d'un .so ou d'un .dll à l'exécution, mais pour l'instant ça fonctionne comme ça donc...
markand a écrit:
Je plussoie. À force de faire trop de généricité et d'overengineering on perd en simplicité et stabilité. Le C++ n'est pas un langage de script c'est un langage statique et compilé.
Si ton but est de « charger » des objets dynamiques pour ton jeu alors un langage de script est plus adapté. Sinon en C++, code tout simplement tes entités directement dans ton application. Les charger dynamiquement n'a absolument aucun bénéfice.
- Edité par markand il y a environ 5 heures
Le problème c'est que comme le gameplay n'est jamais le même suivant le type de jeux, les classes ne sont jamais les mêmes, donc, si je code directement les entités dans l'application je devrai modifier les classes de l'application à chaque fois que je change de jeux. Le fait de charger les objets dynamiquement, m'évite de devoir faire ça, voilà le bénéfice de faire ça, surtout si je ne veux pas que l'utilisateur aie accès au code source de l'application et aie à le modifier mais qu'il puisse créer de nouvelles entités pour son jeux.
Bon j'avoue c'était galère à faire récupérer les informations sur les classes (constructeurs, fonctions membres, etc...) et de créer un .so qui crée les objets dynamiquement car à chaque recompilation et rechargement du .so la mémoire du .so se décharge, j'ai du donc faire tout un bazard. (passer les entités créées avec le .so à l'application et les cloner) En plus j'ai dû aussi supprimer les variables statiques et les remplacer par des variables membres car, elles étaient recréées à chaque rechargement du .so.
Bref ça n'a pas été simple, je le reconnais, il y avait peut être moyen de faire mieux je ne sais pas, c'est la première fois que j'ai à faire quelque chose du genre, mais maintenant que ça fonctionne, ça va me faire gagner un temps fou, éviter de devoir modifier le code de l'application à chaque fois que je crée un nouveau type d'entité pour un jeux, je n'ai juste qu'à copier les fichiers du jeux dans un dossier du projet créé avec l'application et les créer dynamiquement avec l'application, les modifier, etc... et la réflexibilité me permet de ne pas avoir à recréer une nouvelle gui pour créer/modifier un nouveau type d'entité dont je ne connais de toute façon pas la structure à l'avance.
Bref, ODFAEG et ODFAEGCreator n'ont pas été créer dans le but d'offrir de la simplicité et de la stabilité, mais d'offrir un système de généricité et d'over engineering de tel sorte que l'utilisateur puisse faire ce qu'il veut et rendre ça le plus flexible possible en devant modifier le moins de code possible.
ODFAEG permet entre autre de :
-sérialiser des objets (par valeur ou des pointeurs) en utilisant des archives de n'importe quel type afin de sérialiser des objets sans avoir à se soucier du format de fichier (Txt, xml, binaire, etc...) bien que pour l'instant je n'ai fait qu'un type d'archive pour le format txt.
-créer des fonctions de callback et, leur passer des paramètres et aussi utiliser un système comme std::bind et les ajoutés dans un tableau comme ça pas besoin de créer un tableau différent, pour chaque type de fonction de callback.
La réflexibilité permet de créer des menus pour créer n'importe quel type d'objets. (pour ODFAEGCreator)
Le runtime compiler permet de créer des objets dynamiquement. (pour ODFAEGCreator)
Si tu dois modifier ton moteur pour créer un jeu, c'est que tu as un gros soucis de conception, au niveau flexibilité...
Un langage de script va te permettre de communiquer avec ton moteur via une API que tu auras définie et implémentée. Renseigne toi sur Lua, Python (avec Boost.python ça va assez vite). Pour Castor3D, j'ai une API Python et une API COM (pour pouvoir utiliser Castor3D en C# et autres langages Microsoft supportant COM, c'est à dire... presque tous ?)
- Edité par dragonjoker 15 janvier 2021 à 0:30:00
Si vous ne trouvez plus rien, cherchez autre chose.
>comme je crée l'entité avec le .so et que je le delete dans l'application
Il faut donc que votre application et votre ".so" soit compilé avec le même compilateur, les mêmes réglages dans toute la chaîne de compilation et partage la même C-runtime, et aient le même code dans le destructeur, quel ironie quand on cherche à avoir quelque chose qui change tout le temps.
>Je ne connais pas de langage de script
Ca se compte pas centaines et c'est comme si ils tenaient pas le haut du pavé : Python, Lua, Javascript, etc...
>si il est possible d'exécuter une fonction d'un .so ou d'un .dll à l'exécution
Vous confondez but et moyen. Oui beaucoup permettent d'exécuter des fonctions C exporté par une Dll, mais on s'en fout, les scripts se chargent et se déchargent bien plus facilement qu'une Dll native.
Avez-vous commencé par analyser ce qui se faisait dans "l'industrie", avant ?
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Le problème c'est que comme le gameplay n'est jamais le même suivant le type de jeux, les classes ne sont jamais les mêmes, donc, si je code directement les entités dans l'application je devrai modifier les classes de l'application à chaque fois que je change de jeux. Le fait de charger les objets dynamiquement, m'évite de devoir faire ça, voilà le bénéfice de faire ça, surtout si je ne veux pas que l'utilisateur aie accès au code source de l'application et aie à le modifier mais qu'il puisse créer de nouvelles entités pour son jeux.
Alors ton moteur fait trop de choses. Par exemple, si tu veux quelque chose de générique sans que ce soit compliqué; tu peux faire une entité qui sait se dessiner à l'écran en fonction de données simple (géométrie, effet, vélocité). De ce fait, que tu code un shoot em up, un RPG ou un sidescroller ça ne change rien. Ton application se lie à ta bibliothèque et rajoute des nouvelles entités qui vont bien.
Charger des .so/.dll doit rester une opération anecdotique. J'ai jamais vu un quelconque jeu/moteur charger chaque entité de données de cette manière. Comme déjà dit, il n'y a aucun intéret. Tu sépare ton moteur de ton « code de jeu » et lorsque tu initialise ton jeu tu ajoutes les objets qui vont bien à ton moteur, aucunement besoin que ce soit fait dynamiquement.
Exemple :
// Fonction fournie par le « moteur »
void Scene::add(Entity& e);
// Code de jeu de ton application
Entity mario;
Scene scene;
mario.addShape("mario.png");
scene.add(mario);
Dans tous les cas je t'invite fortement à lire le principe KISS.
- Edité par markand 15 janvier 2021 à 10:34:22
git is great because Linus did it, mercurial is better because he didn't.
Et pour les entités personnages par exemple, monstres ou bien pnj, quest je fais comment ? Sachant que les variables de ses classes peuvent changer suivant le jeux.
Parce que il y a les données simples oui (géométrie, etc..) qui sont communes à toutes les entités et que je peux inclure dans ODFAEGCreator, mais pour les autres données, le problème c'est que je ne les connais pas à l'avance et donc pour les créer je dois utiliser la réflexibilité et un .so (je ne peux pas les inclure dans le moteur) pour ne pas avoir à modifier le code source de ODFAEGCreator à chaque fois que je veux créer de nouvelles données.
Je veux faire un peu comme le système d'assets de unity, mais, avec en plus une gui qui permet de créer les nouveaux types d'entité (GameObject avec unity) sans que l'utilisateur aie besoin de modifier le code source de ODFAEGCreator. Donc je fais les include dans le .so plutôt que dans ODFAEGCreator.
Et il y a trois type d'objets :
-Les entités interne à ODFAEGCreator, celles-ci sont crées/modifiées/supprimées avec ODFAEGCreator.
-Les entités externes qui hérite de la classe Entity, elles sont crées et supprimées dans le .so parce que ODFAEGCreator ne connais pas la structure des données à l'avance, pour la modification, les données communes sont modifiées avec ODFAEGCreator et les données non communes dans le .so.
-Les entités externes qui n'héritent pas de la class Entity : ells sont crées, modifiées et supprimées dans le .so.
Bref je veux créer un système un peu comme le système d'assets de unity mais avec en plus une GUI qui permet de créer, modifier ou supprimer ces nouveaux "GameObject" sans devoir modifier le code source du moteur.
Et pour les entités personnages par exemple, monstres ou bien pnj, quest je fais comment ? Sachant que les variables de ses classes peuvent changer suivant le jeux.
Mais c'est toujours pareil. Tu fais une bibliothèque spéciale orientée RPG avec ce que un objet de type PNJ est censé gérer et lorsque tu te lies à cette bibliothèque tu créé autant d'objet que ton scénario a besoin.
Par exemple, tu peux découper ton moteur du style :
engine-core (utilitaires de base)
engine-graphics (gestion très primitives des graphismes)
engine-rpg (spécialisé dans les RPG : quêtes, pnj, etc)
OmbreNoire a écrit:
Je veux faire un peu comme le système d'assets de unity, mais, avec en plus une gui qui permet de créer les nouveaux types d'entité (GameObject avec unity) sans que l'utilisateur aie besoin de modifier le code source de ODFAEGCreator. Donc je fais les include dans le .so plutôt que dans ODFAEGCreator.
Rien ne t'empêche de générer du code C++ tout prêt avec ton éditeur si tu ne souhaites pas utiliser un langage de script. Ensuite, tu compiles ces fichiers sources. C'est ce que font des outils comme des designers UML.
git is great because Linus did it, mercurial is better because he didn't.
Et pour les entités personnages par exemple, monstres ou bien pnj, quest je fais comment ? Sachant que les variables de ses classes peuvent changer suivant le jeux.
Mais c'est toujours pareil. Tu fais une bibliothèque spéciale orientée RPG avec ce que un objet de type PNJ est censé gérer et lorsque tu te lies à cette bibliothèque tu créé autant d'objet que ton scénario a besoin.
Par exemple, tu peux découper ton moteur du style :
engine-core (utilitaires de base)
engine-graphics (gestion très primitives des graphismes)
engine-rpg (spécialisé dans les RPG : quêtes, pnj, etc)
OmbreNoire a écrit:
Je veux faire un peu comme le système d'assets de unity, mais, avec en plus une gui qui permet de créer les nouveaux types d'entité (GameObject avec unity) sans que l'utilisateur aie besoin de modifier le code source de ODFAEGCreator. Donc je fais les include dans le .so plutôt que dans ODFAEGCreator.
Rien ne t'empêche de générer du code C++ tout prêt avec ton éditeur si tu ne souhaites pas utiliser un langage de script. Ensuite, tu compiles ces fichiers sources. C'est ce que font des outils comme des designers UML.
Ouais mais bon tout les rps n'utilisent pas forcément les même variables pour les quêtes, les pnj, etc..., c'est un peu casse gueule je sais bien mais bon...
Si je génère du code c++ compilé avec l'éditeur plutôt que de généré un .so pour créer les entités ça va être galère parce que pour modifier tout ce qui est commun aux entités (géométrie des pnjs, entités enfants pour l'affichage, etc...), je vais devoir modifier le code c++ hors que en faisant un .so qui crée une entité pnj et l'ajoute à l'éditeur, je peux créer une entité Tile par exemple ou Animation avec l'éditeur et réutiliser le code de l'éditeur pour ajouter l'entité tile comme enfant de l'entité pnj, bref, je pense qu'il faudrait que je fasse une vidéo tu comprendrais peut être mieux ce que je veux faire non ?
Non, ou plutôt vu que ton système est écrit dans le marbre alors oui... Tu pourrais faire qu'un composant expose une interface name/type qui te permettra alors d'afficher/modifier ce que tu veux comme tu veux
> Les entités externes qui hérite de la classe Entity
Ton système d'entités est pourri, si tu dois faire ça... (pour te donner une idée, dans mon ECS, une entité est un entier tout con)
Si vous ne trouvez plus rien, cherchez autre chose.
Un moment donné, il va falloir que tu réalises que tu t'es complement planté. Tu fais des choses qui sont complètement WTF, que personne ne fait (un .so sous Windows ???).
Honnêtement, ca me fait penser a un débutant qui a lu le tuto C++ du SdZ, a vu la structure d'un jeu en dur dans le code et s'est dit qu'il allait faire un moteur de jeux basé sur cette architecture.
Mais si personne ne fait ca, c'est pas pour rien.
C'est pas grave de faire des erreurs, a partir du moment ou l'on arrive à se remettre en question. Mets ton moteur de côté et lis des livres de C++, de conception logiciel, d'architecture des moteurs de jeux. Et fais des projets simples.
Ou n'écoutes pas les conseils et fais comme tu veux.
(EDIT : il y un projet ODFAEG sur GitHub, sur Developpez.com sur le forum de la SFML, mais fait par un certain Laurent. Tu dis dans ta bio que tu t'appelles Florian. Vous êtes la même personne ? Ton projet ODFAEG est bien celui sur GitHub ?)
Pour les autres débutants qui liraient cette discussion :
On voir encore et encore les mêmes erreurs chez les débutants et donc on répète encore et encore les mêmes conseils.
1. notre propos n'est pas de vous faire abandonner votre projet. Au contraire, on vous donne des conseils pour que vous le réussissez. Mais cela implique souvent qu'on vous conseille de mettre de côté votre projet, d'apprendre progressivement, de faire des projets intermédiaires.
2. Si vous voulez faire un jeu, utiliser un moteur de jeux. Créer un jeu et créer un moteur de jeux, c'est deux boulot différents.
3. Si vous voulez faire un moteur de jeux... utilisez un moteur de jeux. Ca peut paraitre paradoxal, mais c'est une base en développement : on étudie l'existant quand on aborde un nouveau domaine. Ca veut dire lire des tutos ou livres sur les moteurs de jeux et leur développement, mais ca veut dire aussi utiliser un minimum des moteurs de jeux, pour savoir comment les autres ont fait.
4. Créer un moteur de jeux est une tâche très complexe. Trop complexe pour les débutants. Il faudra avoir de bonnes bases en programmation (donc lisez des bons cours et pratiquez beaucoup), en conception et gestion de projet (ca fait la différence entre un projet qui est réalisé en 1 an, et le même projet réalisé en 10 ans parce que n'importe quoi), et pleins d'autres compétences, qui prennent du temps à acquérir.
Il n'y a pas un choix à faire entre une voie rapide et difficile et une voie lente et facile. Il n'y a qu'une seule voie pour créer un moteur de jeux : une longue et difficile. Il faut beaucoup étudier, beaucoup pratiquer, accepter d'y aller progressivement, faire des erreurs et apprendre de ses erreurs.
Et pour ceux qui ne veulent pas suivre les conseils qu'on donne... à dans 10 ans, avec votre projet qui ne sera pas abouti.
Le seul truc que je pourrais encore modifié c'est faire une interface pour le rendu avec VULKAN mais je ne compte pas utiliser VULKAN.
Là aussi tu fais erreur. OpenGL est une vieillerie infâme bourrée de variables globales et obsolète sans compter la multitude de versions différentes. Si tu as envie de faire un moteur, fais le au moins dans une technologie du futur. Pour info, Vulkan est fait par le même consortium que OpenGL, c'est pas pour rien s'ils ont fait quelque chose de nouveau, hein. C'est comme démarrer un nouveau gestionnaire de fenêtre pour UNIX sous X11 alors que c'est voué à disparaître.
En fait, je pense – sans être méchant – que tu fais un projet déjà obsolète, trop compliqué et aucunement innovant. Mais comme on l'a dit, faire des erreurs fait parti du parcours du débutant, donc tu finiras par t'en rendre compte.
git is great because Linus did it, mercurial is better because he didn't.
Je n'ai pas trouvé beaucoup de tutoriels sur Vulkan et au moment ou j'ai commencé à développer le moteur, Vulkan n'existait pas encore.
Et puis il faudrait changer tout le code du moteur graphique et du module fenêtre c'est beaucoup de boulot si je dois changer le moteur à chaque fois qu'une nouvelle technologie sort je n'aurai jamais fini car ça sort plus vite que le temps que je met à développer le moteur.
Mais je trouve aussi qu'OpenGL n'est pas type top, il est lent, trop de versions donc faut à chaque fois tester si tel version est supportées à chaque rendu, avec l'opengl moderne tel que les bindless textures pour limiter les appels trop nombreux à draw ça irait peut être mieux puisqu'il faut utiliser les nouvelles technologies mais, le soucis aussi, c'est que j'ai besoin de pas mal de FBO pour faire du rendu en plusieurs passes pour afficher les ombres, les lumières, la réflexion et la réfraction, c'est peut être ça qui le ralenti beaucoup bref 60 FPS pour afficher quelques sprites c'est pas beaucoup surtout avec une carte NVidia qui est sensée être puissante bien que assassin's creed tourne à 30 FPS avec les graphismes en ultra et j'utilise des techniques de rendus plus lentes qui je pense ne sont pas implémentées dans Unity tel que les listes chaînées par pixel, et la réflection/réfraction je ne sais pas si ça existe dans unity, jamais entendu parlé en tout cas. Mais peut être que opengl n'est pas tip top pour utiliser ses nouvelles techniques de rendu sur mon ancienne carte j'avais 5 de FPS avec les listes chaînées par pixel, ici 60, je trouve que ça devrait être plus rapide que ça surtout que je fais du batching pour limiter les appels trop nombreux à draw et de l'instanced rendering bien que je ne vois pas l'intérêt de faire de l'instanced rendering parce que bon, on passe moins de sommets mais on passe les matrices de transformations et en plus quand les coordonnées de textures changent faut refaire appel à draw chose qu'il ne faut pas faire si l'on pré transforme tout les sommets avec le CPU et que l'on met tout dans un FBO et que l'on draw.
Ça peut aider déjà pour l'aspect conception générale.
Après chaque composant d'un moteur de jeu requiert des compétences bien particulières, et il serait trop long de fournir toutes les ressources disponibles (j'espère que t'as au moins le livre Real-Time Rendering, et la spec d'OpenGL en bible sur ton bureau pour ton renderer avec un backend OpenGL).
> Mais je trouve aussi qu'OpenGL n'est pas type top, il est lent
Tu n'en es pas à voir les lenteurs d'OpenGL. Si ton moteur est lent, c'est de ta faute (Castor3D est lent, je le sais, je vais pas blâmer le reste du monde pour ça, c'est uniquement de ma faute)
> c'est que j'ai besoin de pas mal de FBO pour faire du rendu en plusieurs passes pour afficher les ombres, les lumières, la réflexion et la réfraction, c'est peut être ça qui le ralenti beaucoup
> j'utilise des techniques de rendus plus lentes qui je pense ne sont pas implémentées dans Unity tel que les listes chaînées par pixel, et la réflection/réfraction je ne sais pas si ça existe dans unity, jamais entendu parlé en tout cas.
Mouahaha ! C'est tellement révolutionnaire, comme technique, l'environment mapping... Et les listes chaînées par pixel, ça existe depuis des années pour l'OIT (et je parle pas de ton bricolage, hein)
> je ne vois pas l'intérêt de faire de l'instanced rendering parce que bon, on passe moins de sommets mais on passe les matrices de transformations
C'est un trade-off, sur desktop ça vaut généralement le coup. Sur mobile j'ai par contre fait autrement.
> en plus quand les coordonnées de textures changent faut refaire appel à draw chose qu'il ne faut pas faire si l'on pré transforme tout les sommets avec le CPU et que l'on met tout dans un FBO et que l'on draw.
Kamoulox
Si vous ne trouvez plus rien, cherchez autre chose.
J'ai trouvé un tutoriel sur Vulkan, purée tout ce qu'il faut gérer juste pour afficher un triangle (presque 1000 lignes de codes) c'est un truc de fou.
Bon j'ai regardé le tutoriel sur le site de chronos et ça fait la même chose qu'opengl mais en beaucoup plus compliqué, je vois pas l'intérêt d'utiliser Vulkan si ce n'est que pour du multithreading mais je ne fais pas de multithreading avec mon framework.
Je ne pense pas que cette api a un futur, tout les débutants vont utiliser opengl c'est beaucoup plus simple et ça permet de faire la même chose.
En plus, comme c'est une nouvelle api il n'y a pas beaucoup de tutoriels et d'exemples, avec le tutoriel de chronos il n'y a juste que le chargement de modèles 3D, il n'y a rien sur le shadow mapping, le stencil buffer, le light mapping, les "per pixel linked list" que j'utilise, les cubemaps, etc...
Je n'ai trouvé qu'un example de code source sur ce repo mais ou sont les shaders ?
Bref je suis déçu de cette nouvelle api, on dirait qu'elle n'est faîte que pour les experts en graphisme (même le tutoriel le dit et conseille opengl pour les jeux et Vulkan seulement pour des apis graphiques de haut niveau) et pourtant elle fait la même chose qu'opengl mais en beaucoup plus compliqué on dirait que chronos a attendu d'avoir une api simple avec beaucoup de versions et d'extensions comme opengl pour la moderniser le plus possible et puis de réunir toutes les fonctionnalités modernes d'opengl dans une api beaucoup plus difficile à utiliser.
Si opengl disparait bonjour tout les débutants (comme moi) vont utiliser un moteur de jeux existant.
Ils devraient au moins fournir une interface simple comme opengl pour gérer les textures, les uniforms buffer objects, les vertex buffer objects, etc..., comme pour opengl.
> Je ne pense pas que cette api a un futur, tout les débutants vont utiliser opengl c'est beaucoup plus simple et ça permet de faire la même chose.
Oui, Vulkan, Metal, DX12, ce sont des API qui vont disparaitre, ils vont revenir sur la merde qu'ils ont fait, pour réhabiliter OpenGL et DirectX11...
> il n'y a rien sur le shadow mapping, le stencil buffer, le light mapping, les "per pixel linked list" que j'utilise, les cubemaps, etc...
Normal, les algos ne changent pas d'une API à l'autre...
> Bref je suis déçu de cette nouvelle api, on dirait qu'elle n'est faîte que pour les experts en graphisme
Oui
> une api simple avec beaucoup de versions et d'extensions comme opengl
Essaie d'utiliser OpenGL de manière performante (renseigne toi sur l'AZDO) et tu verras à quel point ton "API simple" est le véritable enfer à utiliser correctement... (Sans parler de la rétrocompatibilité sur 30 ans) En OpenGL tu as 36 manières de faire la même chose, mais une seule est la bonne, et c'est la plus compliquée
> Si opengl disparait bonjour tout les débutants (comme moi) vont utiliser un moteur de jeux existant.
Et ce sera tant mieux ! Un débutant ne devrait pas utiliser OpenGL ou aucune API graphique, mais un moteur (3D ou de jeu)
> Ils devraient au moins fournir une interface simple comme opengl pour gérer les textures, les uniforms buffer objects, les vertex buffer objects, etc..., comme pour opengl.
Non
> Vulkan c'est l'enfer en fait.
Non, Vulkan est beaucoup plus verbeux, mais aussi beaucoup plus logique.
Si vous ne trouvez plus rien, cherchez autre chose.
Dans ce cas pourquoi ne pas avoir fait vulkan dès le début ça nous aurait évité de devoir changer tout le code du module graphique, moi en tout cas, je ne changerai rien, ça m'a prit 10 ans pour faire le moteur, il est temps de faire un jeux avec, si je dois changer l'architecture et l'api graphique j'en ai encore pour 10 ans.
Pour changer une api comme ça il y a un problème d'analyse là, c'est carrément toute l'api qui change, pour faire la même chose que opengl. (geometry shader, compute shader, vertex shader, fragment shader, textures, cubemaps, SSBO, UBO, FBO, etc...)
Les besoins ont changé mais, vulkan comparé à l'opengl moderne pas tant que ça...
> Pour changer une api comme ça il y a un problème d'analyse là, c'est carrément toute l'api qui change,
Et il était temps, il fallait se débarrasser de l'héritage sur 30 ans d'OpenGL, qui fait qu'on se retrouve encore avec des gens qui pensent qu'OpenGL c'est glBegin/glEnd ! Et ils ne pouvaient pas le faire dans OpenGL, du coup on a une nouvelle API qui est logique
Si vous ne trouvez plus rien, cherchez autre chose.
× 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.
git is great because Linus did it, mercurial is better because he didn't.
Si vous ne trouvez plus rien, cherchez autre chose.
git is great because Linus did it, mercurial is better because he didn't.
Si vous ne trouvez plus rien, cherchez autre chose.
git is great because Linus did it, mercurial is better because he didn't.
git is great because Linus did it, mercurial is better because he didn't.
Si vous ne trouvez plus rien, cherchez autre chose.
Discord NaN. Mon site.
Discord NaN. Mon site.
git is great because Linus did it, mercurial is better because he didn't.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.