Discussion :

[Laurent7601]

Bonjour à tous et à toutes.

Le projet

Je suis entrain de développez un moteur de jeux vidéo et une interface graphique pour éditer des niveaux avec le moteur pour créer mon propre jeux vidéo depuis plus de 15 ans maintenant.

Le dépôt git se trouve ici https://github.com/LaurentDuroisin7601/ODFAEG

Dans le dossier Demo se trouve l'éditeur de niveau et le jeux que je suis entrain de développer.

Je veux un moteur de jeux qui soit très complet et qui me permettra de créer n'importe quel type de jeux facilement, étant donné que je n'ai pas assez d'expérience pour utiliser un moteur de jeux existant tel que unity ou unreal engine mais que j'ai beaucoup d'expérience en c++ et en opengl, j'ai décidé de créer mon propre moteur de jeux, ça me permet de savoir mieux comment l'utiliser et de ne pas être obligé de lire des pages ou lire des vidéos que je ne comprend absolument pas pour utiliser un moteur de jeux vidéo existant. Le moteur de jeux est divisé en plusieurs parties :

Le module core : contient toutes les fonctionnalités de bases du moteur.

Le module math : contient toutes les classes qui gèrent la librairie mathématique.

Le module window : contient toutes les classes qui gèrent le fenêtrage. (Fenêtre windows, linux, sfml, glfw pour vulkan, etc...)

Le module graphique : contient toutes les classes qui gèrent l'affichage. (Rendereurs pour dessiner les entités, les ombres, les lumières, la réflection et la réfraction ,etc...)

Le module physique : contient toutes les classes qui gèrent la physique. (Volumes englobants pour les collisions, les particules, etc...)

Le module audio : gère le son. (La spatialisation du son, jouer de la musique ou des effets sonores, etc...)

La structure du moteur de jeux.

Vous avez d'abord l'application qui contient tout (le monde, les renderers, les fenêtres, les composants guis, les scènes, etc...)
Ensuite vous avez le monde qui contient les scènes et les systèmes pour mettre à jour la scène courante. (Une seule scène peut être active en même temps)
Ensuite vous avez les scènes qui contiennent toutes les entités des différents niveau. (une scène par niveau)
Vous avez les systèmes qui remettent à jour la scène. (Transformation d'une entité, chargement des entités du monde qui sont visibles sur les rendereurs, etc...)
Il y a deux types de systèmes, les timers qui remettent à jour les entités tous les x temps et les workers qui remettent à jour les entités à chaque appel à la fonction update.
Vous avez les rendereurs qui eux affichent les entités. (Affichage des ombres, des lumières, de la réflexion/réfraction, etc...)
Vous avez les entités. Ce sont tout les objets du jeux qui sont affichable sauf les guis et les entités "sfml-like" qui sont à part et qui sont juste des entités Transformable et Drawable. (J'ai utiliser une classe de base Entity dont hérite tout les types d'entités) mais j'ai aussi commencé un système ECS avec entt que j'ai dû laisser tomber car je devais modifier tout le code source des projets utilisant le moteur et je n'ai pas eu de gain au niveaux des performances par rapport à l'héritage alors j'ai laissé tombé le système ECS pour les démos cependant j'ai fait une démo qui utilise entt (ODFAEGDemoEcs) ou l'on peut utiliser un système ECS, on a donc le choix entre utiliser un système ECS ou l'héritage.
Les entités peuvent avoir un partent et des entités enfants, cela implique que les entités enfants héritent des propriétés des entités enfants.
Il y a différents types d'entités. (Les tiles, les mesh, les animations, les lumières, les grandes tiles contenant plusieurs tiles comme la heightmap, un système de particule, etc...)
Après les entités vous avez les hiérarchies de volumes englobants, il y a plusieurs types de volumes englobants : (Les AABB, les OBB, les Sphères, les ellipsoïdes, etc...) les hiérarchies de volumes englobants permettent de faire des tests plus précis de manière plus rapide.
Vous avez le conteneur de renderers qui contient tout les renderes et les guis.
Vous avez aussi les fenêtres qui sont les fenêtres du jeux et les textures de rendus qui sont les textures de rendus du jeux pour le rendu hors écran.
Vous avez les guis comme par exemple les combos box, les boutons, etc... (Mais je dois encore améliorer le look and field des guis parce que c'est moche xd.)
Vous avez également toutes les formes simples de la SFML (les ConvexShape, les CircleShape, les RectangleShape) ceux-ci ne peuvent pas être ajouté à la scènes car ils servent à créer des jeux simples qui ne nécessitent pas forcément l'utilisation d'un framework comme avec la SFML.
Il y a le conteneur qui contient toutes les guis et les rendereurs, il y a deux types de composant de rendus, les composants légé (les guis) et les composants lourds (les rendereurs). La différence entre les deux est que les composants lourds dessinent tout ce qui est complexe et plus long à dessiner tandis que les composants légés tout ce qui est simple à dessiner comme par exemple les guis.


Le Network : gère le réseau. (envoie de paquets, démarrage du serveurs et du client, etc...)
Les users : les utilisateurs réseaux.
Vous avez également les packet, il y a les paquets encryptés avec encyptage non symétrique (RSA) et encryptage symétrique (AES).

Les AudioStreams pour charger et lire des effets sonores ou des musique ainsi que toutes les classes SFML pour la spatialisation du son.

Vous avez les resources managers pour charger des fichiers tels que des images, du sons, des polices de caractère, etc...
Vous avez aussi des archives pour la sauvegarde et le système de sérialisation.

Ce qui est implémenté.

-Possibilité de créer ses propres entités en héritant de la classe Entity.
-Possibilité de créer ses propres types de rendereurs si on veut utiliser ses propres shaders pour rendre les entités et pas ceux du moteur de jeux.
-Possibilité de créer ses propre scènes en héritant de la classe scène manager si par exemple on ne veut pas utiliser la grille virtuelle du moteur de jeux, mais des octrees ou des quadtrees ou une combinaison de ceux-ci, mais pour moi, la grille suffit.
-Possibilité de créer ses propres systèmes, en héritant de la classe Worker ou Timer.
Bien sûr il y a des méthodes à redéfinir impérativement et qui sont appelées par le moteur de jeux.

-Chargement de ressources externes. (textures, sons, polices de caractères, etc...)
-La sérialisation d'objets dans des fichiers textes.
-Récupération d'un chemin (une ligne brisée) entre un point de la souris et le personnage.
-Récupération de la position du personnage sur un chemin en fonction du temps.
-Séparation des chaînes de caractères à l'aide d'un séparateur.
-Calculs de vecteurs de flottants (à 2, 3 ou 4 dimensions). (Produit scalaire, produit en croix, etc...)
-Calculs de matrices de flottants (à 2, 3 ou 4 dimensions). (Déterminant, inverse, etc...)
-Matrices de projection, de transformation et de vue.
-Gestion des textures.
-Gestion des rendus dans des textures. (Textures 2D ou cubemaps)
-Gestion de la lumière. (Lumières ponctuelles seulement pour l'instant avec calcul de l'atténuation en fonction de la distance et de la normale)
-Gestion des ombres. (Shadow mapping avec la lumière du soleil seulement pour l'instant)
-Gestion de la réfraction de de la réflexion. (Dynamic Environment mapping)
-Gestion de la transparence. (Per pixel linked lists)
-Génération de terrains en 2D ou en 3D. (Récupération de la hauteur du terrain à une position x et z pour la 3D)
-Collisions sur les cases de la grille virtuelle. (Si on peut passer dessus ou pas)
-Récupération des entités du monde qui sont visible.
-Tests des collisions entre hiérarchies de volumes englobant.
-Gestions des animations. (interpolation de sommets)
-Index de l'animation courante si une entités possède plusieurs animations.
-Chargements de modèles 3D dans de nombreux formats grâce à la librairie assimp.
-Affichage de modèles 3D.
-Gestion de la caméra.
-Possibilité de dessiner les entités en mode normal ou en mode instanced.
-Affichage de formes simples et du texte à l'écran.
-Affichage de composants GUIS.
-Gestion des évènements avec la possibilité de stocker des fonctions de callback de n'importe quel type de fonctions et de paramètres de fonctions. (fonctions non membres, fonctions membres, fonctions lambda et passage des paramètres par valeurs, par références ou par placeholders)
-Gestion des actions. (Evènements clavier, souris pouvant être combinés avec les opérateurs ou, et, ou exclusif ou le non)
-Lecture du son.
-Spatialisation du son grâce à la SFML.
-Transfert sur le réseau en TCP pour les données importantes (encryptage, plus lent) ou en UDP pour les données moins importantes mais plus fréquentes. (sans encryptage, plus rapide)
-Possibilité de récupérer le temps client pour chaque utilisateurs connecté au réseau.
-Collision de la lumière avec la physique.
-Gestion de particules. (Emitteurs, affecteurs)
-Billboarding. (Transformation des systèmes de particules pour les afficher face à la caméra.)

Optimisations
Indirect rendering. (Pour réduire les drawCalls)
Bindless texturing. (Pour réduire les drawCalls)
Batching pour récupérer tout les tableaux de sommets utilisant les mêmes matériaux et le même type de primitives pour réduire les drawsCalls.
Dereffered shading. (Calculer la lumière seulement à l'endroit ou c'est éclairé)

Voilà ce qui est implémenté et testé.

Implémenté mais encore à tester ou à améliorer.

-Finir l'implémentation Vulkan. (j'ai déjà implémenté vulkan pour le rendu de formes simples avec les classes "RenderTarget et RenderTexture" mais je dois encore le faire pour la gestion de la transparence, les ombres, les lumières et la réfraction)
-Le bump mapping.
-Les composantes spéculaire.
-Tester les collisions avec tout les types de volumes englobants.
-Le raytracing. (Problème de performance (rendu trop long), affichage des ombres et de la réfraction, ok pour dessiner la heightmap (Quads) mais crash du driver pour dessiner un modèle 3D (Triangles)).
-Les lumières directionnelles.
-La génération de labyrinthes en 2D et en 3D.
-La génération de terrain avec des murs autour en 3D.
-Gestion de la physique (escalader, tomber, sauter, voler, etc...)
-L'éditeur de niveau. (Amélioration du look and field des guis, édition de niveaux en 3D, ...)

Pas encore implémenté du tout.

-Gestion d'une map de voxels. (MineCraft)
-Chargement et lecture de vidéos. (Pour les cinématiques du jeux)
-Portage androïd.
-Gestion du joystick.

Avancement du projet

Voir ma chaîne youtube : https://www.youtube.com/channel/UCao...8nWNhpSMz6PQfw

Je recherche actuellement pour le moteur de jeux.

Un développeur Vulkan.

Celui-ci aura pour tâche de finir l'implémentation Vulkan du moteur de jeux, c'est à dire ajouter le code source Vulkan des rendereurs pour les per pixels linked lists, le shadow mapping, le dynamic environement mapping et le lightmapping.

Un UI Designer.
Pour améliorer l'interface graphique de l'éditeur de niveau. (ODFAEG Creator)

Je recherche actuellement pour le jeux.

Un scènériste/game designer.

Pour concevoir l'histoire du jeux et définir le gameplay.

Un dessinateur/graphiste 2D.

Faire tous les graphismes en 2D. (Les items, les guis, etc...)

Un modeleur 3D.

Faire les personnages, les ennemis, les objets et les rendre en 3D iso et faire les tilesets.

Un développeur web.

Créer le site web du jeux, téléchargement du jeux, inscription des nouveaux joueurs, etc...

Un webdesigner.

Design du site web.

Un sound designer.

Sons du jeux, musique, ambiance.

Des développeurs c++.

M'aider à créer le jeux, fait le patcher pour le téléchargements des mises à jour, etc...

Rémunération ?

J'ai fais un système de don mais malheureusement je n'ai pas encore trouvé de donateurs si vous voulez être rémunéré il faudra faire un projet vendable, être sûr d'avoir la motivation jusqu'au bout du projet, je fait ce projet dans le but de gagner plus d'argent pour plus tard.

Voilà c'est tout pour l'instant pour toute personne souhaitant m'aider, vous pouvez me mp en me communiquant votre motivation.

[Laurent7601]

Salut, j'ai ajouté des widgets pour transformer les entités avec l'éditeur.




C'était plutôt amusant à faire.

Le développement de l'éditeur de niveau touche à sa fin, il ne me reste plus que à faire le rendu des ombres et lumières ainsi que à tester le plugin qui se charge de créer/modifier/supprimer des objets qui sont externes au moteur. (Comme par exemple des quêtes, des pnjs, des monstres, etc...)
ODFAEG ne possède pas de classe pour créer des objets du gampleplay, vous devez donc les définir vous même car ODFAEG se veut être un framework générique qui permet de créer des objets défini avec des scripts et en récupérant toutes les informations sur les classes (constructeurs, fonctions et arguments de constructeur/fonction) je peux utiliser une gui avec odfaegCraetor pour entrer les valeurs à l'aide d'une gui pour créer/modifier un objet. Le code pour créer les objets et les modifier se situent dans un .dll ou j'appelle les fonctions à l'exécution.

EDIT : j'ai fait mes propres guis mais le soucis c'est que c'est pas très beau mais je suis programmeur par ui designer et je ne voulais pas dépendre de QtCreator. Le seul moment ou je vais utiliser Qt ce sera pour la connexion à la BD car là pas besoin de générer des fichiers .moc, je préfère utiliser le c++17 pour les events des guis avec fonction de callback génériques. (fonctions lambdas, placeholders, etc...) plutôt que les signaux et les slots QT ou j'ai dû générer des .moc pour codeblocks.

[Invité]

Mdr la boucle


T'as enfin développé ton os, ta carte graphique et tes drivers pour faire tourner tes jeux datant du siècle dernier à 15fps avec un moteur qui ne gère pas bien l'opacité ?

[Mat.M]

Mdr la boucle

c'est facile de critiquer mais au moins Laurent7601 essaie d'entreprendre quelque chose.
Bien qu'il n'a pas les gros moyens comme peut avoir un studio de jeu vidéo.
Et vous, vous avez quelque création à nous montrer ?

[PixelJuice]

c'est facile de critiquer mais au moins Laurent7601 essaie d'entreprendre quelque chose.
Bien qu'il n'a pas les gros moyens comme peut avoir un studio de jeu vidéo.
Et vous, vous avez quelque création à nous montrer ?

Le problème n'est pas là, j'imagine que le post de MytheOuMytho vient du fait que l'OP a une mauvaise réputation sur pas mal de forums francophones de développeurs.

Personnellement, ce qui m'interpelle c'est que Laurent7601 dit d'un côté qu'il faut tout définir dans son jeu, mais en même temps il y a déjà des contraintes et une structure préétablie :

3D iso, histoire, inscription de joueurs (donc il s'agit d'un jeu en ligne j'imagine ?)

Ce qui m'interpelle aussi, c'est :

Je veux un moteur de jeux qui soit très complet et qui me permettra de créer n'importe quel type de jeux facilement, étant donné que je n'ai pas assez d'expérience pour utiliser un moteur de jeux existant tel que unity ou unreal engine mais que j'ai beaucoup d'expérience en c++ et en opengl, j'ai décidé de créer mon propre moteur de jeux, ça me permet de savoir mieux comment l'utiliser et de ne pas être obligé de lire des pages ou lire des vidéos que je ne comprend absolument pas pour utiliser un moteur de jeux vidéo existant. Le moteur de jeux est divisé en plusieurs parties

Qu'est ce qui est le + rapide et le + facile ? Se former sur un des moteurs les + populaires, ou travailler sur son moteur maison depuis 15 ans ? Je dis ça car la finalité du moteur est bien de faire tes propres jeux, non pas d'être viable en tant que produit, à l'instar de Unity. De plus, l'expérience indéniable que tu as accumulé avec la création de ton moteur te permettrais d'apprendre très rapidement car les rudiments et la logique sont très semblables.

Si je devais te donner un conseil, c'est qu'il va falloir un jour sérieusement se poser la question : Tu veux faire des jeux vidéo, ou des moteurs de jeux vidéo ?

Ce n'est absolument pas les mêmes métiers, pas les mêmes problématiques, et pas du tout les mêmes enjeux. Je le dis parce que je suis aussi passé par là et j'avais bossé sur mon propre moteur, très poussé, en ayant même crée pas mal de logiciels tiers, jusqu'à que je me rende compte que j'étais entrain de créer un Unity mais en moins bien, et bien moins complet. Me poser cette fameuse question a été très salvateur et je me suis formé rapidement sur Unity, grâce à l'expérience justement, comme je disais + haut.

Je pense que personne ne peut nier la quantité de travail et d'efforts que tu as fourni, mais il s'agirait de te poser la question le + vite possible, et structurer tout ça.

[Mat.M]

Le problème n'est pas là, j'imagine que le post de MytheOuMytho vient du fait que l'OP a une mauvaise réputation.

qu'est-ce que c'est l'OP ?

[yildiz-online]

...vient du fait que l'OP a une mauvaise réputation sur pas mal de forums francophones de développeurs.

C'est vrai que ses difficultes de communication et son egocentrisme forment un cocktail assez penible quand on interagit avec lui, mais sur le forum du SDZ, il semble s'etre produit une amelioration avec un peu plus d'ecoute de sa part, moins de virulence dans ses propos et meme des tentatives d'aide aux debutants.

Pour ceux qui se moquent ou denigrent son travail (moi en premier), c'est peut etre le moment de faire une pause, voir comment il evolue, et tenter de l'encourager dans cette nouvelle direction.

[Laurent7601]

T'as enfin développé ton os, ta carte graphique et tes drivers pour faire tourner tes jeux datant du siècle dernier à 15fps avec un moteur qui ne gère pas bien l'opacité ?

Non je développe sur windows 10 avec une carte graphique nvdia et le driver de nvidia (game ready driver) et je tourne à peu près à 90 FPS et mon moteur gère l'opacité grâce aux per pixels linked list.
Il faudrait arrêter de critiquer, j'essaye de faire un projet, je n'ai pas les moyens pour créer des jeux comme le font les studios de jeux vidéos, je suis seul sur le projet actuellement.

[Laurent7601]

Salut. Je dois voir cela mais avant assassin's Creed Odyssée tournait à 60 de FPS sur mon pc avec les graphismes au max... Il y a sûrement quelque chose que j'ai mal fait... pourtant je n'effectue qu'un seul appel à draw par shader j'ai essayé de réduire le plus possible les appels à draw avec le bindless texturing l'indirect rendering et le batching. Il n'y a que lorsque je change de shader ou de type de primitive que je rappelle le draw. Même si je dessine dans 10 framebuffers la même scène je pensais pas que ça boufferait autant le FPS.

[LittleWhite]

Pour les performances, la vérité se trouve dans les profileurs, ou tout outil qui remonte des données factuels sur le temps pris par telle ou telle fonctionnalité. D'ailleurs, on ne ferait pas d'optimisation sans ces données .

[Laurent7601]

Ok mais quand je compile sur code::blocks avec l'option -pg je n'ai pas de données en sorties du profiler sinon oui j'avais pensé à l'utiliser.

Je viens de corriger un bug concernant la classe qui récupère toutes les informations sur une classe, j'ai dû trouver un moyen de supprimer tout ce qu'il y avait entre les crochets si il y a du code dans le fichier.hpp ça n'était pas si simple étant donné que dans les crochets des fonctions il pouvait y avoir d'autres crochets pour des if, while, etc...

Après une fois cela de fait c'est facile de récupérer le nom de la fonction et les arguments.

[Laurent7601]

Bonjour, je n'arrive pas à faire fonctionner gprof sous code::blocks ça va être un dur de savoir quelle fonction ralenti l'exécution du code. Mais le problème vient sûrement de mes fonctions de dessin.

Pourtant je ne fait que d'ajouter tout mes sommets dans un VBO avant d'appeler la fonction draw pour tout dessiner en une fois. (Il n'y a que lorsque j'ai des types de primitives ou des shaders différents que je fais plusieurs draws)

Mais j'utilise pas mal de FBO, maintenant toutes ne dessinent pas forcément tout la scène ça dépend de ce que je passe comme type d'entités à mon composant et si c'est une lumière ou un objet rétractable, etc...

Mais la chute du FPS provient de mes fonctions de dessins et je ne comprend comment le simple fait d'ajouter des sommets dans un VBO peut faire chuter ainsi le FPS...

Mais bon il y a deux types de primitives ici, un type pour le terrain des Quads et un pour le modèle 3D des triangles...

EDIT : Sinon je recherche un programmeur qui s'y connait bien en programmation graphique pour améliorer les performances, résoudre ces problèmes de glitchs et finir l'implémentation VULKAN.

[Laurent7601]

gprof fonctionne et apparemment c'est les push_back qui font descendre le FPS.