Tu pars un peu dans tous les sens, et au final rien n'a l'air de vraiment fonctionner, ce serait plus productif de te focaliser sur les problèmes à résoudre et de choisir une vraie ligne directrice.
Avoir 20 FPS sur une RTX 2060 pour afficher quelques sprites 2D, ça me semble quand même drôlement plus prioritaire à améliorer que d'ajouter de l'eau, faire la sync serveur-client, sérialiser les particules...
Si les points critiques ne sont pas fixés, c'est tout le projet qui est au final inutile.
D'ailleurs ça m'étonne que tu aies accès au repository, je l'ai mis privé pour évité des critiques inutiles et donner accès que aux gens qui aident vraiment pour le projet.
Bientôt une vidéo sur ODFAEG Creator, le projet avance bien, une fois ODFAEG Creator fini je repasserai sur le jeux, et je ferai un site de vente.
Je n'ai pas accès, ce n'était pas ma config dont je parlais mais la tienne, il y a quelques messages de ça tu disais tourner entre 16 et 22 FPS(par contre j'ai confondu 2600 et 1660 super).
Mais 50 FPS (sur du 1080p je suppose) ça reste beaucoup trop faible pour être utilisable avec une carte aussi puissante.
J'ai cherché un petit peu les fonctions qui ralentissent et apparemment ça serait le dessin avec les "per pixel linked list".
Ca m'étonne que j'ai un FPS aussi bas avec des "per pixel linked list" pourtant il y a un moment je tournais aux alentours de 300 FPS et puis ça a chuté, j'ai dû modifié quelque chose mais bonne chance pour retrouver ce qui a fait chuté le FPS comme ça...
C'est bien à ça que sert une (ou plusieurs) ligne directrice.
Dès lors que la performance est établie comme élément critique de l'application, il devient naturel de la retester constamment (et de préférence en automatisant) à chaque modification, ainsi, on peut comparer par rapport à une baseline initiale si un changement dans le code affecte les perfs et y remédier si c'est négatif.
Bon, j'ai gagné 20 de FPS en dessinant normalement (sans l'instanced rendering) et en faisant les transformations avec le CPU et mettre tout les sommets dans un VBO comme je faisais avant.
Je suis a 70-80 FPS à peu près, mais c'est encore trop peu, on dirait que c'est depuis que j'ai fais deux sprite batcher dans les composants (un pour l'instanced rendering et un pour le rendu normal) que ça freine l'application.
EDIT : Bon j'utilisais mal l'instanced rendering, parce que je refaisais un draw call lorsque les coordoonées de textures changeaient, au lieu de tout dessiner en une fois, ce qui faisait baisser le frame rate forcément.
- Edité par OmbreNoire 28 décembre 2020 à 19:38:38
Salut! Pour des raisons personnelles je suis obligé de vendre, la nouvelle version est sur un répertoire privé le répertoire publique n'est plus à jour.
Les projets sont déjà bien avancé même si ils ne sont pas tout à fait terminé et je travaille dessus depuis plus de 10 ans.
Le répertoire privé contient :
-Les sources du framework ODFAEG.
-Les sources de la demo, du client et du serveur du futur jeux.
-Les sources de ODFAEG Creator. (Une interface graphique pour utiliser le framework)
Pour recevoir tout il suffit d'acheter le repository pour 50 euros en cliquant sur le bouton paypal sur cette page :
Voilà j'ai pensé que ça serait intéressant pour ceux souhaitant apprendre, débuter dans le milieu et améliorer un code existant et espérer me faire un peu d'argent en ces temps difficile.
Des changements sont prévus dans la version suivante :
-Suppression des variables statiques, les variables statiques de la classe Entity, seront des variables membres dans la classe World, et la classe World ne sera plus statique.
En effet, les variables statiques posent problème et sont créée en double lorsque j'appelle une fonction d'un .dll dans ODFAEGCreator, j'ai essayé de partager les variables statiques mais ça ne fonctionne pas et je trouve ça dégueu comme solution.
Par conséquent, il faudra récupérer l'objet Word unique de l'application pour ajouter les entités au world et passer l'objet world à la classe Map, les entités n'auront pas d'id tant qu'elles ne seront pas ajoutées au world sauf si elles sont récupérées à partir d'un réseau ou chargées à partir d'un fichier bien sûr.
J'ai réfléchi à une solution pour avoir le moins de code source possible à modifier.
EDIT : voilà j'ai supprimé les variables statiques, je n'en ai laissé que une mais celle-là il suffit de l'initialisé en passant le pointeur sur l'application courante donc pas difficile.
J'ai donc mit toutes les variables globales en variables membres dans la classe application, j'arrive maintenant à créer un pnj (d'une classe créée par l'utilisateur) et lui ajouter une tile par contre ce n'était pas une bonne idée de déclarer un vecteur en global dans la .dll parce que à chaque appel de la fonction de la .dll le vecteur est vide, bref, je vais changer ça!
Bon, j'ai essayé de mettre au point un système de plugins avec ODFAEGCreator pour créer des objets externes à ODFAEGCreator, mais ça ne fonctionne pas, j'ai des crashs, donc, je vais devoir abandonner.
Bon j'ai beaucoup travaillé pour mettre au point ce système pour créer des objets dynamiquement avec ODFAEGCreator donc je vais faire un pause en plus ça n'a pas été facile du tout!
Je ne suis plus très motivé j'ai l'impression que ce que je fais c'est de la m**** et encore moins que ça va se vendre.
Oui c'est vrai mais j'ai ajouté des fonctionnalités qui ne sont pas forcément présente dans UE ou Unity et dont j'ai besoin.
Bref le moteur ne se vendra pas mais je vais essayer de le promouvoir en créant un jeux avec...
EDIT : je vais stoppé l'ajout de nouvelles fonctionnalités pour le moment, tout ce dont j'ai besoin est ajouté et il y a des fonctionnalités que je n'ai pas encore eu le temps de tester car il y a déjà beaucoup de fonctionnalités.
Voici la suite des tutoriels sur ODFAEGCreator, comment créer un objet qui ne fait pas partie de ODFAEGCreator, dans la suite, nous verrons, comment modifier ces objets pour ajouter une quête au pnj et les utiliser dans le jeux.
Ben je sais pas dans quel but tu fais ce projet mais si c'est pour autre chose que l'apprentissage ou le fun, ça va être dur, rien qu'en voyant l'interface.
> j'ai ajouté des fonctionnalités qui ne sont pas forcément présente dans UE
Salut! L'interface de ODFAEGCreator n'est pas top mais je vais l'utiliser juste pour créer les maps et autres objets pour mon jeux, je suis totalement incapable de faire une interface comme celle de unity même si j'utilisais une librairie comme qt alors pour m'amusé j'ai décidé de faire mes propres GUI même si c'est dégueu.
J'ai décidé de passer à Vulkan, quitte à perdre un an mais opengl me cause trop de problèmes pour la compatibilité ou c'est l'horreur, il y a pleins de versions différentes et sous windows et android la version d'opengl n'est pas la même (opengl, opengl es, egl, ...) il faut à chaque fois tester si une fonctionnalité est supportée et sinon il faut rendre la scène autrement et il y a 30 façon de faire et avec le driver opensource sous linux (parce que plus de driver propriétaire pour les anciennes cartes graphiques) il faut définir des extensions dans les shader, sur windows non donc le code est encore différent, pour android je ne sais pas de trop car je n'ai jamais développé pour android, mais je pense que les noms de fonctions sont pas les mêmes SFML à même fait un fichier dégueulasse avec tout les pointeurs sur les fonctions opengl mais il n'y a pas les fonctions de opengl 4.6 ça serait un véritable enfer si je devais les définir moi même comme l'a fait la SFML parce que je pense pas que glew les inclus pour android parce que SFML n'utilise même plus glew.
De plus, Opengl n'est pas adaptée pour faire du multi-threading.
Il y aura toujours possibilité d'utiliser opengl mais ces classes ne seront plus maintenues et je pense même les supprimer un jour si j'arrive à faire tout fonctionné avec vulkan, je pense qu'il faut voir l'avenir et je pense qu'à l'avenir, les carte ne supportant pas vulkan vont disparaitre et il se peut bien qu'opengl disparaisse aussi bref...
Vulkan est très difficile à encapsuler car il y a beaucoup d'objets qui dépendent d'autres objets, j'ai lu qu'il fallait créer un UBO par image de la swapchain et donc je peux pas me permettre de juste appeler des fonctions glUniform comme c'était le cas avec opengl mais je dois passer les buffers et les descriptors entre plusieurs classes, bref, c'est un peu galère. Avec opengl fallait juste stocker l'id, et appeler des fonctions et les objets était créer et pour les utiliser glBind, il ne fallait pas passer d'objets entre les différentes classes pour initialiser des structures et les utiliser, c'était moins galère je trouve.
J'ai réfléchi et après réflexion je me suis dis que ça ne valait plus la peine de continuer le projet car il existe de nombreux frameworks concurrents créer par de grande sociétés et qui font sûrement ça mieux que moi, (Unity, unreal engine, Qt, etc...) et je ne pourrai jamais concurrencer ceux-ci tout seul sur le marché.
Salut! Finalement j'aimerais bien continuer le framework, je vais pas le faire payant parce que de toute façon ça n'a aucun intérêt vu qu'il existe de nombreux frameworks concurrents et gratuits et sûrement mieux fait.
Mais j'ai envie de reprendre du plaisir à programmer comme avant.
Et j'ai justement eu une idée pour débuguer mon shader de raytracing et l'optimiser.
Pour débuguer je vais faire une fonction print qui affiche les chiffres d'un nombre sur l'image comme on le ferait sur la console avec un std::cout mais ici ça sera sur une image parce que il n'y a pas de console avec le gpu.
Je vais pouvoir comparer les valeurs que j'ai avec le cpu et avec le gpu, voir pourquoi elles sont différentes et trouver plus facilement ce qui clocher.
Pour optimiser je vais tenter de faire du traitement massivement parallèle en utilisant plus de thread, je vais utiliser un thread pour chaque pixel de l'image mais également un thread pour chaque triangle ainsi un seul thread fera le test d'intersection avec un seul rayon sur un seul triangle.
Pour le calcul des ombres, lumière et la réfraction/réflexion et le blending je devrais stocker des résultats intermédiaire dans des SSBO et faire d'autres compute shaders bien entendu.
Donc j'ai du boulot surtout si je veux ensuite offrir une implémentation pour vulkan mais je vais d'abord le faire pour opengl.
Ca y est l'algorithme de raytracing fonctionne! J'ai mit beaucoup de temps parce que j'avais oublier de ne pas afficher les triangles qui se trouvent trop près et donc il y avait de grands triangles qui venaient cacher des triangles plus petits.
Par contre je n'ai pas encore gérer les textures (le temps est venu pour moi d'essayer les "bindless textures" parce que je ne peux pas utiliser bindTexture parce que pas de pipeline par défaut)
Je n'ai pas encore géré le cas ou le rayon intersecte plusieurs triangles en z.
Et en plus c'est lent il va falloir que j'optimise ça!
Ensuite il faudra encore gérer les lumières, les ombres et la réflexion/réfraction.
Bref, j'ai encore du boulot mais je vais avoir besoin d'aide.
En attendant voici une image de ce qui marche (intersections rayons/triangles et interpolation des couleurs pour les sommets des triangles)
Ca y est j'ai réussi à afficher les textures avec du raytracing et le bindless texturing, j'ai utilisé une liste chaînée de fragments pour les rayons intersectant plusieurs triangles, mais c'est beaucoup trop lent encore il faut que j'optimise déjà ça avant de faire la suite.
Mais avant, je vais faire quelques vidéos sur la structure du framework, les classes, etc... et expliquer mes algorithmes, que je posterai ici (pas de monde sur le forum de ODFAEG), j'espère avoir des retours sur comment optimiser cela parce que le problème de ODFAEG c'est que je me suis basé sur la SFML qui ne fait pas vraiment les choses de manière optimale.
Je vais également commencer à faire des tutoriels vidéos maintenant que j'ai enfin un micro.
Je m'attaque à l'optimisation des performances et j'ai remarqué que lorsque j'utilise plusieurs les "per pixel linked list" lors de la deuxième passe avec le deuxième fragment shader ça fait chuter pas mal les perfs.
Bientôt le support pour le "bindless texturing!", j'ai enfin réussi à le faire fonctionner!!! J'ai mit beaucoup de temps car j'ai eu deux problèmes pour le premier j'ai dû utiliser glVertexAttribIPointer au lieu de glVerttexAttribPointer pour les entiers sinon j'avais pas le bon textureIndex dans le vertex shader et le deuxième problèmes, problème d'alignement donc j'ai dû créer une sous structure avec deux uint64_t pour remplir la mémoire pour aligner tout les "handle" de texture sur 16 octets.
Mais j'en ai un petit peu marre de ne pas avancer (normal en étant seul sur le projet), donc, prochainement je vais avancer dans la création du jeux avec le framework, je crois que je suis bien parti pour commencer à définir un gameplay, l'éditeur de map est presque terminé et le framework aussi.
Le reste ce sera de l'optimisation, de la correction de bugs et plus tard une implémentation pour vulkan mais c'est pas urgent et j'ai envie d'avancer sur le jeux si ça fonctionne avec l'implémentation openGL pour l'instant c'est suffisant.
J'ai fait 4 vidéos expliquant la structure globale du framework sur le forum :
Salut! Ayant un problème avec les drivers sql, je vais devoir générer des pages html manuellement et récupérer des données passées par le navigateur un peu comme le fait JEE en java.
Etant forcé d'utiliser les fichiers pour stocker des données et comme j'utilise un algorithme typiquement en c++ pour sérialiser les données, je ne peux pas utiliser un autre langage pour le faire car il n'y a pas les concepts de template, CFFinae et aussi tout ce qui est test du type pour appeler la bonne fonction de sérialisation pour les objets polymorphique bref toutes ces choses spécifiques que j'utilise en c++ pour lire/écrire des données je ne peux pas les utiliser dans un autre langage.
La seule solution viable que j'ai trouvée est de rajouté une couche au framework qui me permettra de générer des pages html et récupérer des données depuis le navigateur web.
Pour faire cela je vais me baser sur le fonctionnement de JEE en utilisant des librairies tel que CGI pour récupérer les données comme le font les servlets et bien sûr un algorithme qui va générer des pages html à partir des données comme le font les jsp.
Salut! J'ai trouvé un framework c++ pour faire ce que je veux faire, cependant, il me faudra passer à visual studio parce que vcpkg installe des .lib et non pas des .a et pas moyen de compiler les libs avec mingw.
Et quand je converti des .lib en .a avec mingwtools, ça ne fonctionne pas pour toutes les libs, soit j'ai un crash dans le .dll (comme par exemple pour le driver c++) ou des undefined references errors. (avec cppcms)
Salut! Alors voilà j'arrête l'ajout de nouvelles fonctionnalités pour le moment je vais me concentrer sur l'amélioration des fonctionnalités existantes afin d'enfin sortir la version 1 du framework et de ODFAEGCreator!!!
Toutes les classes dont j'ai besoin pour coder le jeux y sont présentes, je n'ai plus qu'à mieux séparer le code et corriger les derniers bugs parce que tout ne fonctionne pas vraiment encore très bien.
Et après je commencerai à coder le jeux d'ici juin mais je fais une pause sur la création du framework. La dernière chose que je vais faire ce sont des tutoriels vidéos. (Parce que pas simple d'expliquer cela avec de la documentation écrite et puis ça prend plus de temps)
A cause d'un bug j'ai dû repasser en 1 contexte par FBO, je n'aime pas faire ça, mais pas le choix, le problème c'est que j'utilise plusieurs buffers et donc avec un seul contexte opengl je dois appeler glBindBufferBase avant et après chaque rendu ce qui provoque l'apparition d'artefacts.
(Il n'y a pas moyen de les bind à l'initialisation du renderer pour la simple et bonne raison que glBindBufferBase ne permet pas de bind un buffer pour un (ou quelques) shaders uniquement.
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl