Je travaille actuellement sur un framework pour la création d'applications ou de jeux vidéos en 2D ou en 3D.
Présentation
ODFAEG (opensource development framework adapted for every game) se veut être un framework flexible permettant aussi bien la création d'application ou de jeux vidéo en 2D et en 3D en n'utilisant qu'une seule librairie!
Le framework utillise une série de petite librairies, pour créer des gros projets de manière simple et efficace.
Le framework est déjà bien avancé, je n'ai pas encore eu l'occasion de tout tester car c'est long de créer un jeux en 2D (un mmorpg) et en 3D (un FPS), et un éditeur de niveau pour l'instant je n'ai fais que des démonstrations mais pas encore de jeux complet.
Je pense faire des débuts de jeux mais je ne pense pas que j'arriverai à faire un jeux complet sans équipe car je ne peux pas faire le site web, les graphismes, les sons tout seul. (Que la programmation)
Fonctionnalités
L'application : elle possèdent plusieurs méthodes pouvant être redéfinie pour les différentes parties du jeux. (Chargement des ressources externes, initialisation, rendu des composants, rendu des overlay, mise à jour des évènements et traitements de fin de boucle. (Messages réseaux, déplacements des personnages en temps réel, etc...)
Scene nodes : toutes les entités peuvent posséder des entités enfants et une entité parente, on peut combiner ainsi les transformations.
La génération de sol : on peut générer un sol en 2D ou une heightmap en 3D.
La grille virtuelle et la matrice de changement de base : Toutes les entités sont stockées dans une grille virtuelle et on peut définir la perspective que l'on veut (par exemple 3D isométrique) à l'aide d'une matrice de changement de base, on peut aussi récupérer toutes les entités visibles d'un ou plusieurs types.
La vue : elle peut être soit en 2D, soit en 3D, pour se déplacer.
Gestion des lumières ponctuelles uniquement.
Gestion des ombres.
Gestion de la semi-transparence dans n'importe quel ordre à l'aide des "per pixel linked list".
Gestion de la réfraction et réflexion.
La sérialisation : permet d'enregistrer n'importe quel type d'objet dans un fichier texte.
Les volumes englobant : permet de gérer les collisions entre entités, il y en a 5 (les boîtes englobantes, les boîtes englobantes orientée, les spheres, les ellipses et les polygones convexes)
La gestion des particules : générations de particules en cercle ou bien en ligne.
Génération d'un chemin (une ligne brisée) d'un point a vers un point b.
Création d'évènements personnalisés grâce aux signaux et aux slots.
Possibilité d'utilisé des "listener" comme en java.
Mises à jour automatiques des animations grâces aux systèmes.
Gestion des animations avec interpolation et squelettique.
Importation de modèles 3D dans de nombreux format grâce à la librairie Assymp.
Interface permettant de choisir la librairies gérant le fenêtrage, (SFML, SDL, GLFW, ODFAEG, etc...) il faut juste changé un define et recompiler. Une personne avait trouvé un moyen de le faire sans recompiler mais je n'ai plus de contact avec lui.
J'ai corrigé quelques bugs depuis, je pense qu'il y en a encore ce sera corrigé au fur et à mesure de l'avancement des jeux pour tester le framework, je pense que pour l'instant il n'y a que moi qui l'utilise.
J'ai ajouté la génération de labyrinthe (en 2D) mais je n'ai pas encore testé. Je n'ai pas toutes les images pour les murs et je n'ai pas de graphiste.
Pour la 3D ce ne sera plus des tiles pour les murs mais des meshs.
Par contre, la compilation est longue, et il faut installer beaucoup de petites libs, avec la commande apt-get et cmake je n'ai pas trop de difficulté.
Le framework ne compile que en mode statique, ça veut dire qu'il faut "linker" toutes les petites libs au projet mais ça va je m'en sors, mais ce ne sera peut être pas forcément le cas de tout le monde.
Le framework n'est pas portable. (Compatible que avec linux)
Sur windows il y a des fichiers que CMake ne trouve pas (hors qu'ils sont présent), le module fenêtre de ODFAEG ne fonctionne donc que sous linux, de plus les shaders n'affichent rien avec le driver propriétaire, bref, mesa le driver opensource fonctionne mieux. (Même si j'ai quelques bugs/crash avec j'arrive à passer outre)
Salut! J'ai corrigé un bug dans la classe PerPixelLinkedList! Maintenant on peut utiliser plusieurs linked list sans que ça ne crash.
Mais par contre, c'est lent! Je ne peux pas utiliser deux linked list pour le sols et pour le reste sinon ça rame. (2 FPS) Mais si je n'en n'utilise qu'une j'ai que 9 FPS et sans je n'ai que 15 FPS. Mon PC a plus de 10 ans, il commence à ramer même pour aller sur Internet et avant j'avais plus de FPS.
Je crains que je ne doive acheter un nouveau PC. :/
Je ne sais pas si quelqu'un d'autre utilise le framework, ne fuse que de me dire à combien de FPS ça tourne ça sera déjà bien.
Je ne vois pas comment l'optimisé surtout que je l'avais déjà optimisé en utilisant des accès indexés plutôt que des accès séquentiels ce qui avait doublé le FPS. (Avant j'arrivais a 30 FPS)
Hello, si ça compilait sous Windows, je pourrais tester, mais où est-ce que ça bloque?
Je ne pense pas que les Linked List soient essentiels pour faire du OIT. Qu’est -ce que tu vise, les plateformes High-end, quel public cible? En utilisant ce genre de feature tu limite en quelque sorte la portabilité, comme tout ce qui est Smartphone, WebGL etc. J’ai aussi quelques doutes sur les performances des Linked List, je pourrais t’en parler plus en détail après avoir fait quelques tests en OIT.
Il n’y à que la persévérance qui paye, Bonne continuation 😉
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Ça compile sous windows et en utilisant le module fenêtre de sfml (en rajoutant define SFML on peut le faire tourner sous window.)
Par contre il y a pas mal de dépendances à installer. Sous linux c'est facile avec apt-get mais sous windows j'ai eu plus de mal, en plus CMake ne trouvais pas certains fichiers si je met des accents par exemple je n'ai pas ce problème sous linux.
Sous windows le driver ne supporte que opengl 4.1 et donc pas de linked list en plus les shader pour afficher les ombres et lumières ne fonctionnent pas, je n'ai pas ce problème sous linux. Pas moyen de trouver un driver plus récent qui fonctionne, à moins de compiler mesa pour le faire tourner sous windows, ça règlerait sûrement le problème. J'ai lu qu'on pouvait l'installer sous windows mais je n'ai jamais essayé, enfin si mais j'avais eu un problème je pense.
Il existe d'autres technique que les linked lists, j'ai essayé le weighted blended OIT qui est plus rapide mais malheureusement j'ai des tiles qui ne s'affichent pas surtout quand il y a de la transparence, avec les linked list ça fonctionne mais c'est plus lent.
Je vise surtout un publique utilisant les dernières versions du logiciel gratuit et libre.
J'aimerais bien savoir à combien de fps ça tourne avec ubuntu 18.04 et un PC plus récent pour savoir si je dois racheter un PC (le mien commence à ramer, au démarrage ça va mais après...) ou bien si c'est mon code qui est trop lent mais personnellement je ne vois pas comment l'optimisé plus, j'avais essayé les vbo mais le fps était toujours aussi bas.
Ps : j'ai du recodé le module fenêtre de la sfml sous linux car j'ai eu des plantages avec le module fenêtre de SFML lors de l'utilisation de plusieurs fenêtre.
Je ne compilerai pas, je suis très mauvais dans le développement de jeux vidéos. Cependant, je vois que la documentation a beaucoup évolué depuis la dernière fois que j'ai regardé ce sujet. Bravo pour tout le travail abattu !
Je vais remettre à jour la documentation d'ici quelque jours car certaines choses ont changé. Déjà pour l'installation il y a plus de petites libs à installer, entre autre la librairie assymp que j'utilise pour charger des modèles en 3D.
Il y a aussi un nouveau composant de rendu : PerPixelLinkedList! Je pense que je ne vais garder que se composant là car les autres techniques d'OIT que j'ai testé ne fonctionnent tout simplement pas.
Correction d'un bug iWindow::filterEvent(const IEvent& event) = 0;
Comme j'avais oublié le const il appelait la méthode de la classe parente et retournait faux et donc la méthode pollEvent retournait false au lieu de true et du coup les évènements n'étaient pas déclenchés.
J'ai rendu la méthode abstraite comme ça plus de problèmes.
Par contre il se passe quelque chose de bizarre avec Ubuntu 18.04 tout les menus de ODFAEGCreator s'affichent en décalé et tout ne s'affiche plus correctement. (C'est brouillé) la fileDialog n'affiche plus rien. Je n'ai pas se problème avec ubuntu 14.04. Mais le problème avec ubuntu 14.04 c'est qu'il n'y a que la version 11 de mesa dessus hors moi j'ai besoin de la version 19, j'ai essayé de compiler mesa sur ubuntu 14.04 mais c'est vraiment la merde il faut le compiler avec meson et j'ai eu un module _lzma qu'il ne trouvait pas hors que je l'avais installé bref...
J'ai à la fois une bonne et une mauvaise nouvelle.
La bonne c'est que j'ai retrouvé un code source de l'ancien éditeur de map codé avec Qt.
La mauvaise c'est que je vais devoir modifier ce code, le projet utilise encore SFML 1.6 et le framework n'existait pas encore, mais on peut y retrouver les tout début du framework avec les classes map, gridmap et cellmap.
Je suis tout ému d'avoir retrouvé ça sur source forge :
Je pense que je vais coder les interfaces graphiques avec Qt et ne plus utiliser celles du framework comme ça plus de problèmes. (Sauf pour le jeux ou là j'utiliserai les interfaces graphiques du framework)
- Edité par OmbreNoire 22 décembre 2019 à 22:32:55
Salut, j'ai amélioré le composant pour afficher les ombres, parfois elles ne s'affichent pas au bon endroit mais on peut les replacer, on peut aussi les retourner, chose que je fais en 2D mais aussi en 3D.
Désormais on n'est plus obligé de changé le centre pour les ombres de toutes les frames d'une animation mais seulement le centre pour l'ombre de l'entité racine c'est à dire l'animation par exemple.
Personnellement il n'y a plus grand chose à faire à part des guis pour des cases à cocher et des boutons d'options. Je ne sais pas encore si je vais faire un système pour lire des vidéos, ça serait bien si un jour j'ai une équipe pour faire un scénario mais ce n'est pas pour tout de suite.
Je vais bientôt avoir un nouveau PC. (Une tour, pas un portable parce que avec un portable on ne sait pas changer la carte graphique ni le processeur quand ils sont mort)
J'ai une ancienne tour et un ancien écran mais ils ne vont plus et le PC a plus de 20 ans, ainsi j'aurai un portable et une tour, de plus, sur mon portable la carte graphique est AMD, sur la tour ça sera une nvidia, je pourrai donc tester le moteur avec différentes configurations. Sur le portable je vais laissé linux, et sur la tour windows 10.
J'ai repéré un bug avec le projet de l'éditeur de niveau, pour le positionnement relatif des UIs et les layouts, lorsque je redimensionne la fenêtre les composants UIs ne se redimensionnent pas.
Je vais essayer de corriger ce bug au plus vite.
A oui il faut savoir que, contrairement à d'autres framework, ODFAEG utilise openGL pour dessiner les UIs. (Le glScissor marche bien)
Les composants décalent tous vers la gauche, comme si je passais de la position 0x en -yx hors que je ne change pas la position, j'ai même remis à jour le viewport lors du redimensionnement de la fenêtre mais rien n'y fait.
J'ai tenté une compilation du framework sous windows 10 mais cela à échoué le compilateur (je compile avec la console et cmake) m'indique qu'il ne trouve pas les fichiers de la SFML en #include.
J'ai tout essayé, même en mettant le dossier include de la SFML dans la variable d'environnement path, le compilateur ne trouve pas les fichiers.
Le dossier SFML est dans le même dossier que celui de mingw c'est à dire dans C:/Programmes.
Je ne sais pas trop quoi faire à part continuer avec linux, là, tout est pré-configuré et pré-installé il n'y a qu'à téléchargé les paquets et ça fonctionne mais avec windows c'est la merde.
Par défault, ODFAEG utilise le module fenêtre de ODFAEG qui ne gère que la création de fenêtre sur linux, pour windows il faut préciser que l'on veut utiliser la SFML comme librairie pour le fenêtrage cela se fait dans le fichier config.hpp il faut rajouté #define SFML.
C'est normal, j'utilise mon propre compilateur Cwc.
J'ai corrigé le problème de posix
Encore une erreur par contre :
../ODFAEG/src/odfaeg/Window/windowFactory.cpp: In static member function 'static odfaeg::window::IWindow* odfaeg::window::WindowFactory::create()':
../ODFAEG/src/odfaeg/Window/windowFactory.cpp:18:35: error: invalid new-expression of abstract class type 'odfaeg::window::SFMLWindowImpl'
return new WindowType();
^
In file included from ../ODFAEG/src/odfaeg/Window/windowFactory.cpp:3:
D:/Data/autre/Test/ODFAEG/ODFAEG/include/odfaeg/Window/sfmlWindowImpl.hpp:8:15: note: because the following virtual functions are pure within 'odfaeg::window::SFMLWindowImpl':
class SFMLWindowImpl : public IWindow, public sf::Window {
^~~~~~~~~~~~~~
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Tiens c'est bizarre sous linux ça compilait avec SFML. Il faudrait que je regarde ça mais comme mingw ne trouve pas les fichiers include de SFML, ça va être difficile.
Sous linux j'ai du recodé le module fenêtre de SFML parce que ça plantait avec SFML, sous windows je ne sais pas jamais pu testé.
Ahlalala, il reste énormément de travaille à faire.
J'ai compilé à peu près 75% du moteur. Par contre, après avoir corrigé quelques milliers d'erreurs, je me rend bien compte qu'il y a encore énormément de boulot pour rendre ça fonctionnel.
J'ai remarqué autre chose, tu semble utiliser également la SDL2 en même temps que la SFML. Bref, c'est un vrai casse tête.
Je peux toujours faire un "Fork/Pull Request" de ce que j'ai, ça serait déjà un énorme pas en avant pour toi.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
J'ai fais des classes générique pour ne pas devoir changer le code si je voulais passer de SFML à SDL2 et pour qu'on puisse choisir la librairie de fenêtrage. (ODFAEG, SFML, SDL2 ou GLFW)
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Site personnel : Julien Gidel - AutoMate - PHPresentation
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.