Discussion :

[Laurent7601]

Oui c'est vrai tu as raison! Je ne vais pas le faire car personne ne l'achètera. Personne ne fait de don déjà alors...

Je vais plutôt parler des futurs mises à jour de ODFAEG :

-Après le portage à vulkan, je compte continuer l'interface graphique du moteur, il ne me restera plus que la gestion des scripts à faire, voici comment ça va se passer pour la gestion des scripts :

-Lors de la création du projet trois scripts sont générés (main, application.h et application.cpp) la génération dépend du type d'application. (Serveur, client ou simple application, plus tard application web ou androïde)
L'éditeur utilisera l'héritage, mais dans les scripts générés je compte utilisé une architecture ECS pour tirer parti des avantages et inconvénients des 2 systèmes! (Les entités seront donc converti en entités de l'architecture ECS dans le script du jeux, ODFAEG génèrera le code pour vous pour les objets affichables ainsi vous ne devrez pas vous en charger)

Ensuite il y aura la possibilité d'ajouter d'avantages de scripts, les scripts peuvent être de plusieurs types :

-Type 1 : Les scripts de définition des objets, scripts pour l'éditeur : ces scripts définiront quels sont les variables de vos objets (par exemple, point de vie, etc...) ces scripts pourront également contenir quelques fonctions pour ajouter par exemple, une quête à un objet de type pnj. Les objets peuvent hérité d'une classe (par exemple la classe entité) ou pas si par exemple les objets ne sont pas affichable dans le niveau ni transformable. L'anima box de l'éditeur (une interface graphique) vous permettra de créer des objets ou les modifier pour par exemple ajouter une quête à un objet pnj, si l'objet est affichable et transformable vous pourrez ensuite, par exemple, attacher des objets affichables avec l'éditeur à vos objets monstres, pnj, etc...

-Type 2 : Scripts de comportement des objets, scripts du jeux : Dans ces scripts vous pourrez par exemple définir de nouveaux composants pour les entités (par exemple, point de vie, etc...), oui il y aura duplication de certaines variables mais c'est pour tirer avantage des deux types d'architectures, vous pourrez ensuite définir des systèmes comme par exemple pour une factory pour créer un nouveau game object de type monstre et lui attacher une entité affichable créé avec l'éditeur. (Grâce aux systèmes de clonage ou à la fusion des composants des entités vous n'avez pas besoin de créer un script et un objet affichable pour chaque entité de même type), vous pourrez ensuite définir le comportement des entités dans les méthodes init() et update() comme avec le moteur de jeux unity.

Ce système avec deux types de scripts permettra de tirer avantage des deux type d'architectures vous pourrez alors définir un système de blue print (comme avec unreal engine) pour créer ou modifier vos objets dans l'éditeur et ensuite attacher des scripts à vos objets (unity) grâce à un système ECS pour définir les comportements de ses objets. Parce que je trouve que le système de blueprint est trop complexe pour gérer le comportements des gameobjects.

Le code de la classe application ne sera pas caché (comme avec unity) vous pourrez par exemple modifier l'état de vos game objects à l'aide d'un slot et gérer l'IA de vos objets dans un script attaché à une entité. (par exemple un empty)

ODFAEG supportera donc deux types d'architectures, mais aussi deux api de rendu (vulkan et opengl) et sera multiplateforme. Le but d'odfaeg c'est de créer des fonctionnalités non présente dans les moteurs de jeux existant. (Sinon ça n'a pas de sens autant réutiliser un moteur de jeux existant)
Et c'est la raison pour laquelle j'ai décidé de créé mon propre moteur parce que j'ai besoin de fonctionnalités non présente dans d'autres moteurs de jeux et d'un moteur de jeux vraiment générique comme par exemple appel de fonction de callback avec gestion de placeholder permettant de créer n'importe quel type d'application ou bien de jeux vidéo. (Minecraft, jeux en 2D iso, jeux en 2D, jeux en 3D, ou même mixer la 2D et la 3D)

J'ai déjà implémenté pas mal de fonctionnalités mais il y a encore beaucoup à faire comme travail et ODFAEG a de beau jours encore devant lui.

[PixelJuice]

Et c'est la raison pour laquelle j'ai décidé de créé mon propre moteur parce que j'ai besoin de fonctionnalités non présente dans d'autres moteurs de jeux et d'un moteur de jeux vraiment générique comme par exemple appel de fonction de callback avec gestion de placeholder permettant de créer n'importe quel type d'application ou bien de jeux vidéo. (Minecraft, jeux en 2D iso, jeux en 2D, jeux en 3D, ou même mixer la 2D et la 3D)

Ben Unity fait déjà tout ça en fait, UE la plupart aussi sans doute mais je ne l'utilise pas. Pour être depuis quelques années maintenant développeur de JV, il y a littéralement 0 projets sur lequel je me suis dit "Tiens, je ne peux pas le faire avec Unity / UE". Et quand tu te penches sur les Studios qui utilisent Unity et qui ont des besoins très spécifiques et absents du moteur, ils font leur propre code en C++ pour pouvoir y remédier. Il est même utilisé pour faire des applications de téléphone. Je ne dis que c'est parfait mais ça te permettra de faire 99.9% des projets que tu veux faire, et je ne pense pas que le jeu que tu veux faire soit dans les 0.01% restants.

En plus tu cites Minecraft mais c'est l'un des rares jeux ou utiliser un moteur de jeu est une très mauvaise idée, voir même contreproductif. Il faut tellement tout gérer pour optimiser que tout ce qu'apporte un moteur ne sert à rien et alourdi même le jeu. Au final tu te retrouves à devoir gérer la génération de Mesh, les chunks, les monstres (et j'en passe) toi-même. Donc au final n'importe quel API ou Framework de rendu 3D suffit.

---

Je répète ma question mais quelle est la finalité de tout ça finalement. Tu veux être créateur de JV ou créateur de moteur de JV ?

[Bousk]

Si vous voulez pas perdre de temps avec les futures inepties de ce topic, vous pouvez lire l'original ici - et constater que rien n'a changé en 11 ans
J'annonce la couleur : version payante, non payante, éditeur, Vulkan, en fait Vulkan c'est pas ouf, veut faire mieux que UE et Unity, problèmes avec sa carte graphique, puis sa carte mère, son OS, compilateur, performances ridicules mais c'est la faute à litérallement tout sauf le code, quelques râles sur le fait que personne ne le prenne au sérieux, qu'il n'a plus de budget, de temps, abandon du projet, reprise du projet, ...
et j'en passe tellement ça part dans tous les sens bien que rien de tout ça ne fasse grand sens
ensuite ça boucle sur tout ça dans un ordre à priori aléatoire

[Laurent7601]

Heu c'est facile de critiquer ?!? Déjà je n'ai pas beaucoup avancer depuis 11 ans car j'ai eu des périodes de burnout de plusieurs mois voir années ou j'ai dû aller à l'hôpital et ou je n'ai rien fait. Maintenant au sujet des autres problèmes (performances par exemple), j'y travaille et j'ai déjà réussi à les améliorer avec les deux apis (opengl et vulkan) même si ça reste sans doute trop bas. Je n'ai pas ajouté vraiment de fonctionnalités au framework depuis un moment et le passage à vulkan m'a fait perdre presque un an et je n'ai pas encore fini, je n'ai donc pas pu bosser sur l'éditeur et je ne pourrai pas avant de finir la nouvelle version avec vulkan finalement j'aime bien utiliser. J'ai eu en effet pas mal de soucis avec mon code et j'en ai sans doute encore je pourrai sans doute encore optimiser. Mais le noyau de ODFAEG à au moins le mérite de rester simple à comprendre (pour moi en tout cas) et comme le noyau du moteur est fonctionnel (avec opengl et bientôt avec vulkan), il suffira juste de rajouter des couches comme avec l'éditeur (je l'ai déjà bien commencé) le projet avancera plus vite. (Je n'ai plus de problème de burnout donc...)

[Laurent7601]

Salut! Finalement, grâce à la réflexibilité du noyau de ODFAEG, je vais pouvoir générer des scripts pour convertir les entités définies par le développeur ou les entités du moteur en entité ECS. Je peux en effet récupérer des informations sur les classes, j'ai une classe qui se charge de lire les fichiers .h et récupérer toutes les informations sur les classes comme en java. La librairie standard du c++ ne permet pas de le faire.

Je sens que ça va être puissant, je n'ai pas l'intention de faire mieux que les moteurs de jeux existant mais au moins faire un moteur qui va me permettre de créer mon futur jeux ça sera déjà pas mal.

[PixelJuice]

je n'ai pas l'intention de faire mieux que les moteurs de jeux existant

On lui demande même pas ça à ton moteur, juste de faire tourner un clone de Pong à 60 FPS.

[Laurent7601]

On lui demande même pas ça à ton moteur, juste de faire tourner un clone de Pong à 60 FPS.

Oui je l'ai fait le code est encore dans le repository mais sûrement plus adapté avec la nouvelle version du moteur car ça fait longtemps donc je ne sais pas si il compile encore.

Avec opengl j'avais réussi à faire un rendu à 60 FPS avec un mmorpg en 2D isométrique que je n'ai pas encore terminé, mais je compte faire un éditeur pour le moteur pour finir le jeux car je trouve que ça serait plus pratique et le code serait mieux séparé et plus clair avec un système de scripts attaché aux entité comme avec Unity. Car pour l'instant le code du mmorpg est un peu chiadé.

Sinon voici deux rendu que j'ai réussi à faire avec vulkan mais je dois optimisé le FPS est encore trop bas comparé à opengl :

[Laurent7601]

Salut! J'ai discuté avec mon frère, il va s'acheter un nouveau PC en janvier, il possède une RTX 3060 maintenant il va s'acheter une 5060 et me faire un nouveau PC avec son ancienne carte graphique pour pas trop cher.
Je pourrais alors enfin faire du raytracing, j'ai envie de me concentrer sur le rendereur de mon moteur, c'est la partie que je préfère, j'aurais peut être dû faire un moteur de rendu plutôt que un moteur de jeux enfin bref... D'ici là j'en aurai fini avec le rendu au rasterizeur. (Je ne vais pas plus loin pour l'instant au niveau de l'amélioration des graphismes pour le rasterizeur)

[Laurent7601]

Bonjour à tous! Je pense que j'ai trouvé, pourquoi c'est lent avec vulkan, j'ai parlé avec une streameuse qui développe aussi un moteur de jeux, elle m'a dit que lorsqu'elle n'utilisais pas le double/triple buffering pour les buffers (VBO, SSBO, UBO, etc...), c'était lent.

Je pense que opengl le fait automatiquement pour cela que la version opengl est plus rapide mais avec vulkan il faut tout faire explicitement donc c'est plus compliqué. Maintenant que j'ai fini le multi-threading je vais m'attaquer à cela donc au double/triple buffering.

[Laurent7601]

OPTIMISATION RELEASE!!!

Salut! J'ai trouvé pourquoi c'était lent avec la version vulkan! Il fallait juste que je double/triple buffer tout mes buffers et images, j'ai gagné plus de 20 FPS maintenant j'ai le même FPS qu'avec opengl. ^^

[LittleWhite]

Et même pas un petit graphique, sans chiffres ni précision :
Exemple:

[Laurent7601]

Bonjour, je suis passé de +/-5 FPS à +/-30 FPS en mode Debug, en mode release je peux avoir plus encore.

Désolé je ne sais pas faire de graphs..., je ne connais pas d'outil pour le faire...

[PixelJuice]

N'hésite pas à upgrader tes outils aussi, de nos jours tu peux enregistrer des morceaux de vidéos ou d'écran en 2 clicks. Ca sera mieux qu'un PNG rempli de blanc au lieu d'être croppé

Regarde du côté de ShareX, Lightshot, OBS.

Du coup les FPS qu'on voit c'est par frame ? ou une moyenne toutes les x secondes ?

[Laurent7601]

Salut, c'est par frame. Nouvelle mise à jour, je mets à jour et génère les sommets pour les particules avec un compute shaders pour tirer parti du double buffering comme cela je peux mettre à jour les particules, pendant qu'il les dessine! Par contre je n'ai pas vraiment de gain au niveau du FPS parce que je ne dessine pas beaucoup de particules mais avec un grand nombre de partricules ça peut optimiser. ^^

[dragonjoker59]

Et arrête de compter des FPS...
Compte les millisecondes par frame, c'est ça qui t'intéresse toi, en tant que dév.
Et évidemment en release, pas en debug...

[Laurent7601]

Tu veux dire faire un std::chrono pour voir le temps écoulé entre deux frames ?

[LittleWhite]

Tu veux dire faire un std::chrono pour voir le temps écoulé entre deux frames ?

Oui.

[Laurent7601]

C'est vrai que compter le FPS n'est pas très représentatif surtout en multi-threads, j'ai un FPS bas ok mais c'est très fluide. Par contre, je ne sais pas très bien comment gérer les ombres avec les pentes, je sais qu'il faut calculer quelque chose avec la normale de la pente que je peux avoir facilement avec le depth texture mais je ne sais pas le calcul qu'il faut faire, je suis vraiment nul en math, je crois que je vais demandé à une IA ça aide beaucoup il m'a déjà répondu à beaucoup de questions et c'est plus rapide que d'avoir une réponse sur les forums et parfois pas de réponse. Voici à quoi ressemble mon rendu en 3D pour l'instant.

PS : pour l'instant j'ai fais un bête depthtest pour tester si l'ombre est visible ou pas mais ça ne suffit pas il faut aussi bien projeter l'ombre avec la normale..., mais je vois pas comment calculer ça dans le fragment shader...

EDIT : ah bah l'IA vient de me donner une formule. ^^

[PixelJuice]

Mais du coup question : Le moteur tournait bien avant ou ça a toujours galéré ? C'est depuis l'ajout de Vulkan ? Tu pourrais aussi faire un petit jeu pour voir comment ça tourne ça serait parlant, un simple Flappy Bird suffirait je pense.

[Laurent7601]

Salut, pour répondre à ta question, je trouve que le moteur tourne mieux depuis l'ajout de vulkan je trouve parce que vulkan supporte le multi-threading contrairement à opengl ou c'était la galère. Du coup c'est plus fluide.

Avec vulkan je peux :

-Créer un grand buffer et faire des offsets grâce aux dynamique descriptors sets, plus besoin de mettre à jour les buffers entre chaque passes ça réduit le nombre de copie.
-Je peux enregistrer des commandes dans plusieurs commandes buffers et les exécuter plus tard et avec la séparation des stagings buffers je peux faire l'enregistrement des commands buffers secondaires et la copie dans les stagings buffers dans un threads et soumettres tout dans le thread principal ce qui réduit aussi le nombre de copies que je dois faire.
-Je peux faire du double/triple buffering en préparant le rendu pour la frame n+1 pendant que la frame1 est dessinée ce qui a booster beaucoup le FPS et encore je n'ai que 2 frames en vols je pourrais changer la constant et en mettre3 ça serait encore plus rapide je pense mais avec deux c'est bon.
-Je peux également calculer les animations et particules de la frame n+1 pendant que celles de la frame n s'affichent.
-Je peux créer plusieurs pipelines à l'avance/descripteurs et bind le bon et grâce au fait que je ne suis pas obligé de remplir un buffer à fond avant avant de l'utiliser comme avec opengl et qu'on peut faire des tableaux de buffers je ne suis plus obligé d'update les descripeurs sets à chaque frames. Juste passer l'index du buffer par push constant.
-Pas besoin d'update les buffers si je ne connais pas le nombres de textures que je vais utiliser à l'avance grâce au descriptor indexing.
-Pas besoin de géometry shader pour dessiné dans un layer d'une cubemap grâce aux multiviews.

Bref grâce à tout ça c'est beaucoup moins galère et le rendu est beaucoup plus fluide, au départ je n'avais fait toutes ces optimisations et j'utilisais vulkan comme j'utilisais opengl du coup c'était lent (plus lent que avec opengl) et très galère.

Le moteur est massivement multi-thread : j'ai un thread pour le frustrum culling et je pense faire aussi du double buffering pour mes batchers pour pas que le culling soit trop hors tard par rapport au rendu qui est en double buffering, j'ai un thread par passe de rendu, un pour les per pixels linked lists, un pour les réfractions/réflection, un pour les ombres et un pour les lumières ce qui rend le moteur beaucoup plus fluide j'ai aussi un thread pour calculer les particules et un autre pour calculer les animations squelettiques.

Et plus tard quand je continuerai la physique je vais rajouté un thread pour calculer la physique et un pour le réseaux. Il n'y a que l'exécution des commandes primaires qui seront gérées dans le thread principal.

Vulkan est vraiment puissant quand on sait comment l'utiliser, c'est un régal pour les expérimentés du rendu et plus facile je trouve qu'opengl, plus efficace à tout les niveaux, même pour le debuguage grace aux validations layers et à debugPrintfEXT! Me manque plus qu'une RTX dans deux mois pour faire du raytracing!

PS : j'ai réussi à amélioré le rendu des ombres avec l'atténuation avec la normale des pentes :



Les ombres suivent bien les pentes j'adore!!!