Forum de la communauté SFML

Général => Projets SFML => Discussion démarrée par: Lolilolight le Janvier 07, 2014, 02:18:39 pm

Titre: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Janvier 07, 2014, 02:18:39 pm
Présentation du projet

ODFAE est un framework pour SFML que je développe depuis plusieurs années déjà dans le but de créer un jeux vidéos complet. (De n'importe quel type)

Le but est de fournir un framework le plus complet possible afin de créer n'importe quel type de jeux.  (Et devenir ainsi le framework de création de jeux par excellence.)

Le code source du framework est régulièrement remis à jour et implémente déjà des nouvelles fonctionnalités du standart c++11 (les threads et primitives de synchronisation, les tuples, les lvalue, les std::functions, etc...) ainsi que certains design pattern. (le pattern facory, type erasure, entity system, singleton, etc...)

SFGL est un projet opensource vous pouvez donc faire part de vos idées afin d'améliorer la structure du code source.

La version 1 devrait sortir vers le mois de févrirer-mars mais en attendant vous pouvez toujours aller rechercher les sources sur github : https://github.com/Lolilolight/ODFAEG/tree/master/src/odfaeg (https://github.com/Lolilolight/ODFAEG/tree/master/src/odfaeg)

Vous pouvez aussi si vous le souhaiter consulter mon devblog :
http://lolilolightdevblog.wordpress.com/ (http://lolilolightdevblog.wordpress.com/)



Les fonctionnalités.

Voici une liste des fonctionnalités implémentées (ou en cours d'amélioration) :

-Un entity system.
-Un système de signal et de slots.
-Un système d'actions.
-Un système de gestion de ressources.
-Un système de states.

Les fonctionnalités à venir dans les versions futures.

-Un système de réseau avec cryptage SSL et prédiction de mouvement.
-Un moteur de particule.
-Gestion de la 3D. (Chargement de fichier.obj, génération de terrain, éclairage, physique, etc...)

Certains tutoriels sont déjà en cours de rédaction sur ce site :

Chapitre I :

http://www.jeux-libres.com/tutoriaux/tuto-679-chapitre-introduction-et-installation-de-sfgl.php (http://www.jeux-libres.com/tutoriaux/tuto-679-chapitre-introduction-et-installation-de-sfgl.php)

Chapitre II :

http://www.jeux-libres.com/tutoriaux/tuto-680-chapitre-entity-systeme-de-sfgl.php

Chapitre III :

http://www.jeux-libres.com/tutoriaux/tuto-684-odfaeg-ombre-lumieres-et-animation.php

Versions futures

Version II

Ajout de la partie réseau du framework, et ajout de la physique afin de préparer la version III.

Version III

Ajout de la 3D.
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Lolilolight le Janvier 10, 2014, 04:26:54 pm
Un nouveau chapitre viens juste d'être rédigé (voir le 1er post de ce topic pour les mises à jours), ce chaptire porte sur les lumières, les ombres et les animations.

Bref encore un chapitre à rédiger, un peu d'ordre dans le code source et la version I sortira enfin!

Pour la version II, je prévois d'implémenter un système de particule ainsi que d'améliorer tout ce qui est plus relatif à la physique. (collisions plus précises avec des hiérarchies de volumes englobants, etc...) ainsi que le réseau et la prédiction de mouvement.

J'ai déjà le code source sous la main pour le réseau mais pas encore pour les hiérarchies de volumes englobants qui seront surtout une préparation pour la version III du framework qui incluera la 3D!

Bref je vais faire un update du 1er post qui parlera des versions future.
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Lolilolight le Janvier 11, 2014, 01:01:25 pm
Re, une bonne nouvelle, j'ai réussi à simplifier l'écriture au niveau des template lors de la création d'actions et lors la connection de signaux.

J'ai remis à jour les tutoriels et le code source.  :)

Une classe du genre "action map" ne devrait pas tarder à arriver pour simplifier la liaison de plusieurs sf::Event à un seul signal.

PS : mais je dois encore trouver une solution pour le passage de références.
PS 2 : un système de placeholder sera implémenté surement aussi plus tard, dès que j'aurai trouvé comment faire ceci : http://accu.org/index.php/journals/1397 (http://accu.org/index.php/journals/1397) avec des std::tuple à argument variable plutôt que des std::list.
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Lolilolight le Janvier 12, 2014, 11:22:34 am
Rajout d'une classe "ActionMap" qui permet de gérer les combinaisons d’événements plus facilement.

Ce qui devrait clôturer normalement la version I du framework, la suite portera majoritairement sur des corrections de bug/optimisations, le rajout d'une classe pour gérer une action avec 2 signaux  (un pour faire et un autre pour défaire une action), car j'en ai besoin pour mon éditeur de map, et du nettoyage de code source/génératon de documentation et exemples.
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Lolilolight le Janvier 13, 2014, 11:42:19 am
Amélioration du resourcemanager :

-L'alias peut désormais être de n'importe quel type. (et plus uniquement de type std::string)
-Rajout d'une fonction qui permet de créer sa propre fonction pour charger ses ressources et la passer au ressource manager.
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Lo-X le Janvier 13, 2014, 11:46:06 am
Et si tu ouvrais un devblog pour y donner tes ajouts quotidiens et que tu n'utilisais le forum que pour les versions majeures et les questions qu'on te pose ?
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Lolilolight le Janvier 13, 2014, 12:57:15 pm
Salut, heu, existe t'il un site qui permet de faire un devblog ou bien faut il en fait un soit même ?

Le problème c'est que je n'ai pas le temps de faire tout ça moi même, je suis seul pour tout faire (et je ne parle pas que de mon travail) et le développement de cette librairie me donne déjà assez de boulot.

Bref si cela vous dérange, je n'apporterai que les nouvelles en ce qui concerne les mises à jour majeures ici, et pour répondre aux questions.
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Laurent le Janvier 14, 2014, 07:50:33 pm
Ce serait bien oui, merci.
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: G. le Janvier 14, 2014, 08:35:04 pm
Tu peux utiliser Wordpress.
wordpress.com si tu veux un blog directement hébergé.
wordpress.org si tu veux télécharger Wordpress et l'héberger toi-même.
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Lolilolight le Janvier 15, 2014, 09:20:26 am
Ok je vais regarder de ce côté là, merci. :)
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Lolilolight le Janvier 15, 2014, 01:29:19 pm
Voilà j'ai update le 1er topic en mettant un lien vers mon devblog... (mais il n'est pas encore fini je dois écrire encore tout le système mur, lumières et ombrage)
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Lolilolight le Janvier 30, 2014, 04:34:31 pm
Plop, la version RC vient juste d'être postée sur mon git-hub (c'est la version sans la documentation et sans les tutoriels)
La 1ère version arrivera donc très bientôt.

Elle comprend :

-Un "Entity system". (Animations, "Scene nodes", systèmes de mise à jour de la scène, une grille pour le stockage des entités et le monde. (qui contient tout le reste))
-Un moteur de lumière.
-Un système d'états pour sauvegarder et restaurer des états sans devoir tout recharger.
-Un système de "listener" pour connecter des actions ou des "triggers" et leur passer des paramètres.
-Un système léger de gestion de ressources.

La version 2 arrivera très bientôt aussi avec en plus :

-Un système de réseau sécurisé. (Avec openssl)
-Un système de prédiction de mouvement.
-Un moteur de particules.


 
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: christophedlr le Février 04, 2014, 09:29:30 am
Projet prometteur (ça me rassure de ne pas être seul à vouloir faire un tel projet ;) ). Je regarderais plus en détail quand j'aurais le temps.
Titre: Re : [ODFAEG] (OPEN SOURCE DEVELOPMENT FRAMEWORK ADAPTED FOR EVERY GAME)
Posté par: Lolilolight le Février 04, 2014, 10:05:47 am
Salut!

J'ai trouvé une solution pour le stockage des ressources de types différents avec des identifiants de différents types. (std::string, enums, etc...)

J'ai rajouté également une méthode wait dans le listener car j'avais des problèmes de synchronisation au rendu.

Bref je mettrai ça à jour lors de la sortie de la release qui est prévu pour le 1er mars! (Juste le temps pour moi de finir la documentation et les tutoriels)

PS : pour les tutoriels je compte faire un .txt et l'intégrer dans le git-hub plutôt.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Février 12, 2014, 05:48:52 pm
J'ai revu certaines choses, et j'ai amélioré :
-Stockage des entity managers avec des identifiant de différents types dans le cache.
-Ajout d'un state dans la classe entity afin de pouvoir ajouter des attributs personnalisés pour chaque type d'entité, avec en plus un exécuteur personnalisé pour remettre à jour les states des entités. (Ceci évite de devoir utlisé trop d'héritage)

Et quelques corrections. (Entre autre dans mon "event buffer")

Tout cela sera remis à jour avec la documentation le 1er mars.

Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Février 13, 2014, 10:21:37 pm
Voilà aujourd'hui j'en suis au dernier chapitre et je vais créer un exemple de petit jeux avec ODFAEG.
(Rien d'extraordinaire, juste un personnage qui taperas des monstres et un système d'xp que je ferai ensuite en réseau avec la prédiction de mouvement pour la prochaine version de ODFAEG)
Des trucs que j'avais déjà préparé à l'avance donc et ou j'avais déjà posté des vidéos. (Malgré ma difficulté à faire des animations)
Mais il y a un dernier point ou je sèche un petit peu c'est pour les animations dynamique.

Le problème c'est que les animations dynamique comme par exemple celles du personnage peuvent soit se trouver derrière ou devant des décors, je n'ai rien trouvé de mieux que de faire une fonction à redéfinir (isMovable) pour savoir si je dois insérer l'entité après ou pas, et dans l'entity manager, j'insère l'entité dynamique au bonne endroit après avoir inséré toutes les autres entité.
En gros je fais un test pour savoir si le centre de gravité des décors est devant ou derrière celui de l'entité dynamique, si oui, j'insère le décor dans un des deux vecteurs suivants. (before ou behind)
Ensuite j'efface le vecteur avec toutes les entités visibles, j'insère toutes les entité qui sont derrière l'entité dynamique, puis j'insère l'entité dynamique, puis j'insère toutes les entités qui sont devant l'entité dynamique.
Ca à pas l'air de laguer mais je me demande ce que ça va donner lorsque j'aurai plus d'entité dynamique. (sors, monstres, ...)
Si quelqu'un à une meilleur solution à me proposer je suis preneur. ;)
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Février 15, 2014, 02:57:49 pm
Attention!!!

Les liens vers les tutoriels ne sont plus à jour, donc, je fournirai un tutoriel au format word que j'inclurer dans le git-hub. (Je pense que tout le monde peut lire se format le cas échéant merci de me le signaler avant le 1er mars)

En effet, désormais, pour les entités animées, il ne sera plus nécessaire de faire autant de tests dans la boucle d'affichage ce qui alourdissait trop le code source, donc, j'ai optimisé le tout et désormais, seuls l'entité courante de l'animation est insérée dans le std::vector d'entités visible.
Et lorsque l'entité courante de l'animation change, l'entity system remets à jour l'entité courante visible de l'animation dans l'entity manager.

Ce qui permet de simplifier le code source :

 getWindow().clear(sf::Color::Black);
            std::vector<Entity*> entities = theMap->getVisibleEntities("E_GROUND");// draw the ground.

            for (unsigned int i = 0; i < entities.size(); i++) {
                getWindow().draw(*entities[i]);
            }
            entities = theMap->getVisibleEntities("E_WALL+E_DECOR+E_ANIMATION+E_CARACTER");
            renderTextShadows->clear(Color::White);
            for (unsigned int i = 0; i < entities.size(); i++) {
                if (entities[i]->getType() == "E_SHADOW_WALL" || entities[i]->getType() == "E_SHADOW_TILE") {
                    renderTextShadows->draw(*entities[i]);
                }
            }

            View view = getWindow().getView();
            Vector2f v2 (view.getCenter().x - view.getSize().x * 0.5f, view.getCenter().y - view.getSize().y * 0.5f);
            rect.setPosition(Vector2f(v2.x, v2.y));
            rect.setFillColor((Color(100, 100, 100, 128)));
            rect.setSize(Vector2f (view.getSize().x, view.getSize().y));
            renderTextShadows->draw(rect, RenderStates(BlendAdd));
            renderTextShadows->display();
            Sprite shadows (renderTextShadows->getTexture());
            shadows.setPosition(v2.x, v2.y);
            getWindow().draw (shadows, RenderStates(BlendMultiply));
            for (unsigned int i = 0; i < entities.size(); i++) {
                if (entities[i]->getType() == "E_TILE")
                    getWindow().draw(*entities[i]);
            }
 AmbientLight::getAmbientLight()->setColor(Color(255, 255, 255));
            Color ambientColor = AmbientLight::getAmbientLight()->getColor();
            renderTextLights->clear(ambientColor);
            entities = theMap->getVisibleEntities("E_PONCTUAL_LIGHT");
            for (unsigned int i = 0; i < entities.size(); i++) {
                renderTextLights->draw(*entities[i], BlendAdd);
            }
            renderTextLights->display();
            Sprite lights (renderTextLights->getTexture());
            lights.setPosition(v2.x, v2.y);
            getWindow().draw(lights, BlendMultiply);
            // end the current frame
            getWindow().display();
 

Désormais dans la boucle d'évènement, on est plus obligé d'attendre que tout les événements SFML aient été traité avant de mettre à jour l'affichage grâce au listener, et grâce au entity system, la frame suivante est préparée dans un thread pendant que la frame courante s'affiche ce qui optimise le temps d'exécution :

  sf::Event event;
        if (getWindow().pollEvent(event))
        {
            listener.pushEvent(event);

            if (event.type == sf::Event::Closed) {

                running =false;
            }
            if (event.type == sf::Event::KeyPressed || event.type == sf::Event::KeyReleased) {
                listener.setActionParams<MyAppli, sf::Keyboard::Key, sf::Time>("MoveAction", this, event.key.code,realTime.restart());
            }
            if (event.type == sf::Event::MouseMoved) {
                Vector2f mousePos = Vector2f(event.mouseMove.x, event.mouseMove.y);
                listener.setParams<MyAppli, MyAppli, Vector2f> ("MouseInside", this, this, mousePos);

            }

        }
 
void keyHeldDown (sf::Keyboard::Key key, sf::Time elapsedTime) {
        sf::View view = getWindow().getView();
        if (key == sf::Keyboard::Key::Z) {
            view.move (0, -speed * elapsedTime.asSeconds());
        } else if (key == sf::Keyboard::Key::Q) {
            view.move (-speed* elapsedTime.asSeconds(), 0);
        } else if (key == sf::Keyboard::Key::S) {
            view.move (0, speed * elapsedTime.asSeconds());
        } else if (key == sf::Keyboard::Key::D) {
            view.move (speed * elapsedTime.asSeconds(), 0);
        }
        getWindow().setView(view);
        renderTextShadows->setView(view);
        renderTextLights->setView(view);
        BoundingRectangle br (view.getCenter().x - view.getSize().x * 0.5f, view.getCenter().y - view.getSize().y * 0.5f, view.getSize().x, view.getSize().y);
        eu->setViewRect(br);
        au->setViewRect(br);
        eu->update();
    }
 

Si la frame courante n'est pas prête à être affichée alors le thread courant est mis en pause jusqu'à ce que l'entity system aie fini d'update la frame courante ensuite a frame courante est affichée et la frame suivante se prépare en même temps.

Les entity system se charge de mettre tout à jour pour vous donc (les animations, et les entité visible pour la frame suivante à chaque fois que l'on déplace la vue), et le listener se charge de traiter les événements à chaque tour.

Désormais les entités animées peuvent être définie comme étant "movable" en redéfinissant la fonction isMovable de la classe AnimatedEntity.
Si l'entité est movable elle sera insérée dans le std::vector des entités visible de l'entity manager à chaque fois que l'on rendra la frame courante et non pas à chaque fois que l'entity system remettra à jour le std::vector des entités visible de l'entity manager.
En effet, contrairement aux animations statiques (C'est à dire les animations dont les entités ne bouge pas et ne font que de s'afficher les unes après les autres), la position en z des entités des animations dynamique tel que un personnage ou un monstre n'est pas connue à l'avance.(Les entités des animations d'un personnage peuvent être soit devant ou derrière un mur par exemple)
ODFAEG recherche donc toutes les entités qui sont derrière et devant l'entité movable, et l'insère au bonne endroit dans le std::vector juste avant que l'on veuille l'affiché l'entité movable. (Et donc précisément au moment ou l'on appelle la méthode getVisibleEntity de l'entity manager.)
Cette recherche est effectuée en fonction du centre de gravité de l'entité, par défaut c'est le centre des segments des entités, on peut le changer avec la fonction changeGravityCenter.
(Bien sûr le sol ne possède pas de centre de gravité, donc, cette recherche n'est pas faîtes pour les entités qui composent le sol)
Bref du lourd donc de prévu pour le 1er mars avec un premier système d'intelligence artificielle et d'xp.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Laurent le Février 15, 2014, 07:57:58 pm
Citer
je fournirai un tutoriel au format word que j'inclurer dans le git-hub. (Je pense que tout le monde peut lire se format le cas échéant merci de me le signaler avant le 1er mars)
Typiquement on fait des PDF quand on veut que tout le monde puisse les lire.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Excellium le Février 15, 2014, 09:39:21 pm
Pourquoi faire un système d'expérience ? Tu crois que tous les jeux utilisent ce système ? On pourrait dire la même chose pour l'intelligence artificielle, ou le réseau, mais c'est déjà un peu moins spécifique à un type de jeu (quoi-que). Et puis quand bien même, pourquoi voudrait-on utiliser ceux-là plutôt que nos propres systèmes ? Sinon n'hésite pas, avant de te lancer dans tous les sens (et maintenant que t'as une base solide), à nous pondre quelques mini-jeux d'exemple histoire qu'on voit mieux les possibilités de ton framework, et pourquoi pas poster quelques screenshots des résultats. :)
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Février 16, 2014, 08:55:23 am
Ha ok, alors je vais plutôt faire un mini jeux et poster des Screenshots comme tu dis. :)

Mais il y avait une chose encore qui me trottait la tête, comment affiché les équipements du personnage ? (Du moins pour les jeux qui en utilise)
Alors j'ai trouvé ceci comme solution : affiché les parties d'armure par dessus la tile du personnage comme si on affichait une ou plusieurs bordures.
Dans la classe Tile il y aura donc une fonction addOverlay supplémentaire qui permettra d'affiché un ou plusieurs sprite par dessus la tile. (Et je crois que je vais aussi par la même occasion rendre tout les sprites de la tile dans une renderTexture afin de générer l'ombre)


Bref comme tu dis je commence à avoir une solide base alors je me suis dis autant essayer de créer un mini-jeux pour voir les dernières fonctionnalités qui pourraient manquer, mais, j'avais pas vraiment d'idées.


PS : Ok je convertirai les tutoriels en format pdf. ;)
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Février 16, 2014, 05:49:47 pm
Re, j'ai changer aussi le système de scene node pour ne plus combiner les transformations dans la fonction draw, dès que je change la position de l'entité parent (ou la rotation ou l'échelle) elle est combinée avec celle de l'entité enfant et je récupère la matrice finale dans la fonction draw de chaque node.

void Entity::draw (RenderTarget &target, RenderStates states) const {
    states.transform = getTransform();    
    onDraw(target, states);
    for (unsigned int i = 0; i < children.size(); i++) {      
        children[i]->draw(target, states);
    }
}
void Entity::setType(string sType) {
    int iType = getIntOfType(sType);
    if (iType == -1) {
        type = pair<int, string> (nbEntitiesTypes, sType);
        types->insert(type);
        nbEntitiesTypes++;
    } else {
        map<int, string>::iterator it = types->find(iType);
        type = *it;
    }
}
string Entity::getType () const {
    return type.second;
}
void Entity::setId (int id) {
    this->id = id;
}
int& Entity::getId () {

    return id;
}
int Entity::getTypeInt () {
    return type.first;
}
int Entity::getIntOfType(string sType) {

    std::map<int, string>::iterator it;
    for (it = types->begin(); it != types->end(); ++it) {
        if (it->second == sType)
            return it->first;
    }
    return -1;
}
std::string Entity::getTypeOfInt (int type) {
    std::map<int, string>::iterator it = types->find(type);
    return it->second;
}
void Entity::addTexture(sf::IntRect textRect, const sf::Texture* texture) {
    TextureDef *tDef = new TextureDef();
    tDef->texture = texture;
    tDef->textRect = textRect;
    textDef.push_back(tDef);
}
const sf::Texture* Entity::getTexture(unsigned int textUnit) const {
    if (textUnit < 0 || textUnit > textDef.size())
        throw Erreur (22, "No texture!", 0);
    return textDef[textUnit]->texture;
}
sf::IntRect Entity::getTextureRect (unsigned int textUnit) {
    if (textUnit < 0 || textUnit > textDef.size())
        return sf::IntRect(0, 0, 0, 0);
    return textDef[textUnit]->textRect;
}
void Entity::addChild (Entity* child) {
    children.push_back(child);
}
void Entity::removeChild (Entity *child) {
    vector<Entity*>::iterator it;
    for (it = children.begin(); it != children.end(); it++) {
        if (*it == child)
            it = children.erase(it);
        else
            it++;
    }
}
//Return the children of the entities.
std::vector<Entity*> Entity::getChildren() const {
    return children;
}

//Return the number of entity's children.
unsigned int Entity::getNbChildren () {
    return children.size();
}
void Entity::setParent(Entity *parent) {
    this->parent = parent;
}
Entity* Entity::getParent() const {
    return parent;
}
int Entity::getNbTextures () {
    return textDef.size();
}
void Entity::onMove(Vec2f &t) {
    for (unsigned int i = 0; i < children.size(); i++)
        children[i]->move(t);
}
void Entity::onScale(Vec2f &s) {
    for (unsigned int i = 0; i < children.size(); i++)
        children[i]->scale(s);
}
void Entity::onRotate(float angle) {
    for (unsigned int i = 0; i < children.size(); i++)
        children[i]->rotate(angle);
}
 

Et j'ai oublié tout ce qu'il y avait dans le tutoriel sur se site parce que j'avais des problèmes de mises à jour de position des entités enfants.

Et comme je me base sur la position des entités enfants pour récupérer tout ce qui est visible et pour les collision bah... -_-

Vous remarquerez que j'ai mit 2 origines (une pour la rotation et l'échelle : c'est le centre des entités) et une autre pour la translation. (c'est la position des entités)
Mais je vois pas l'utilité mettre 3 origines différentes pour la rotation, l'échelle et la translation donc je vais en laisser que 2 pour le moment.
Car j'avais des problèmes de positionnement avec les sprites SFML lorsque je voulais faire des transformations par rapport à plusieurs origines, je devais à chaque fois calculer de combien je devais bouger. (Bref, c'était compliqué)
Mais ODFAEG permettra de palier à ce problème. (Enfin fini tout ces calvaires!)
PS : le développeur pourra choisir de combiner les transformations ou pas avec les entités enfants, si il veut les combiner il ne fera rien. (sauf si il doit transformer d'autres entités comme par exemple les entités physique)
Alors il devra faire ceci :
 void onMove(Vec2f& t) {
            Entity::onMove(t);
            TransformMatrix tm;
            tm.setTranslation(t.x - getLocalPos().x, t.y - getLocalPos().y);
            tm.setOrigin(getCenter().x, getCenter().y);
            for (unsigned int i = 0; i < segments.size(); i++) {
                Vec2f orig = segments[i]->getOrig();
                Vec2f ext = segments[i]->getExt();
                orig = tm.transform(orig);
                ext = tm.transform(ext);
                segments[i]->setOrig(orig);
                segments[i]->setExt(ext);
            }
            for (unsigned int i = 0; i < getPoints().size(); i++) {
                tm.setTranslation(t.x - getPoints()[i]->x, t.y - getPoints()[i]->y);
                *getPoints()[i] = tm.transform(*getPoints()[i]);
            }
        }
 
Entity::onMove combine la translation de l'entité avec celle des entités enfants, si vous ne voulez pas combiner les transformations alors il faudra redéfinir la méthode onMove sans appelé Entity::onMove() :

void onMove(Vec2f &t) {}
    void onScale(Vec2f &s) {}
    void onRotate(float angle) {}
 

Voilà donc encore une nouveauté qui vous attends dans la release!  :)
Bref au niveau affichage j'ai presque terminé l'amélioration du code source.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Février 25, 2014, 03:22:24 pm
Voici un 1ère exemple de ce qu'on peut faire avec ODFAEG!

(J'ai juste besoin de retravailler les animations du héro et de rajouté des ennemis et des projectiles et j'aurai un 1er example de jeux complet. :) (Enfin!)

http://www.youtube.com/watch?v=nkzkRWISFN4&feature=youtu.be
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Mars 09, 2014, 01:23:16 pm
Salut, ça faisait un moment que je n'ai pas donné de nouvelles et bah en voici :

-J'ai commencé à coder la partie 3D du framework et je pense même essayer de mixer la 3D et la 2D, j'espère sortir la release finale pour la fin de l'année.

Le but étant de créer un framework adapté pour des jeux de genre très différents. (FPS, Hack and slash, mmorpg, etc...)

Et de réunir toutes les fonctionnalités offertes par un ensemble de projets SFML déjà existant (SFNUL, SFGUI, la THOR library, etc...) en un seul framework. (Voir même d'aller encore plus loin en permettant de faire de la 3D tout en utilisant l'abstraction que nous offre SFML sur le code opengl)

Le buts visés sont donc les suivants :

-Créer un seul framework unique et standard qui soit multi-plateforme. (J'en ai besoin pour mes projets personnels et je ne tiens pas à réinstaller à chaque fois les librairies sur toutes les plateformes que j'utilise. (Windows, linux, ....)

-Créer un framework flexible, et indépendant c'est à dire qu'on est pas obligé d'utiliser toutes les fonctionnalités du framework et qu'on peut délégué certaines tâches à d'autres framework si ODFAEG n'offre pas la possibilité de faire ce que font certains autres framework.

-Proposer plusieurs possibilités de développement au développeur. (Par exemple soit il utilise un système de signaux, de slot et d'actions ou bien il hérite d'une interface KeyListener par exemple comme en java)

Bref voilà ça c'était un petit message pour ceux qui souhaiteraient contribuer au projet.

En ce moment j'aurai moins de temps car je vais commencer une grosse formation dans le but de décrocher un stage et je l'espère enfin un travail mais c'est pas pour autant que je laisse tombé mes projets personnels qui me seront, je l'espère, très utiles en cas de pépin.








Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Avril 23, 2014, 09:29:25 am
Salut, j'ai update le répertoire git-hub il y a dorénavant un tutoriel en français et un exemple de code source qui montre comment utiliser la librairie.

J'ai plus que a faire quelque tests avec le modules réseau et intégrer le système de particule de thor + 2- 3 routines pour améliorer la structure du code source et générer la documentation avec doxygen, ensuite, je lancerai la release de la 2ème version. :)


Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Juillet 20, 2014, 08:58:49 am
Voila j'ai terminé le réseau et le système de collision ce qui clôture la version 2 du framework!

Le réseau. (https://www.youtube.com/watch?v=D51qTfjewQ8)

Les collisions :

[ (http://youtu.be/bJbWODne5-g)

Maintenant je vais créer quelques jeux en 2D pour fêter ça.  :D (Et pour tester le système de particule)

Je posterai les vidéos ici. :)

Ensuite je vais essayer d'améliorer mon moteur de lumière, de créer des classes pour générer des terrains en 3D ainsi que pour charger des formats de fichier de modèles en 3D et enfin adapter SFGUI avec mon système de signal et de slots pour avoir quelque chose de similaire à Qt.

Je pense que je vais ensuite finir sur des drivers pour SGBD, la sérialisation, les jeux sur navigateur, mais bon ça c'est moins sûr car il y a déjà beaucoup de boulot avec tout le reste!

Ca dépenddra donc surtout  si je suis toujours solo ou pas pour la dernière partie.
Bien que un driver SQL j'en ai quand même besoin d'un donc je vais essayer d'en intégrer un tout fais au framework ça m'évitera de devoir utiliser une dépendance supplémentaire juste pour ça!

J'ai essayé d'apporter un support pour l'opengl moderne mais les drivers ne semble pas encore bien supporter l'opengl moderne sur ubuntu 14.04. (même les drivers propriétaire de amd ne fonctionnent pas)

Bref ce n'est pas urgent, c'est surtout pour la 3D que ça risque de me poser quelque problème au niveau des perfs si je peux pas utiliser l'opengl moderne. :/

Donc c'est pas urgent, vu que la 3D, c'est pour plus tard, j'ai dû commencé avec peu d'expérience et de moyens donc...
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: G. le Juillet 20, 2014, 06:50:04 pm
C'est voulu que quand ton personnage fonce dans la maison il soit pas bloqué pile contre le rectangle blanc mais à une distance plus ou moins aléatoire ?
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Juillet 20, 2014, 07:27:44 pm
Citer
C'est voulu que quand ton personnage fonce dans la maison il soit pas bloqué pile contre le rectangle blanc mais à une distance plus ou moins aléatoire ?

Oui car mon algorithme recherche le chemin le plus court entre deux cases, donc, le centre de la case ne se trouve pas toujours pile poile contre le rectangle blanc de la maison, il y a aussi le fait que j'arrondis les "float" en int pour accélérer les tests donc, il reste parfois un petite espace ce qui n'est pas grave vu que l'essentiel c'est que le personnage ne passe pas à travers la maison, de plus, je n'afficherai bien sûr pas les rectangles dans le jeux.

Je me suis aussi trompé pour la taille en z de la box du personnage :

 odfaeg::RectangleShape rect2(odfaeg::Vec3f(caracter->getCollisionVolume()->getSize().x, caracter->getCollisionVolume()->getSize().y, 0));
 

J'avais mis caracter->getPosition().z au lieu de 0 donc..., le rectangle du personnage se rétrécissait (et s'agrandissait) à l'affichage uniquement.

Mais là maintenant c'est mieux.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Juillet 23, 2014, 03:32:54 pm
Grande nouvelle !!!

J'ai réussi à introduire boost dans le répertoire de mon framework (la license le permet), du coup, je vais pouvoir sérialiser mes entités avant de les envoyer sur le réseau.

En effet, les entités de odfaeg sont complexe (et peuvent parfois contenir des animations qui peuvent elles même contenir d'autres animations, les entités peuvent aussi contenir des volumes englobants, etc...)

Donc bon, envoyer ça sur le réseau c'est la galère. :/

Je pense donc que je vais tout sérialiser dans des fichiers à l'aide de boost, et ensuite, je vais envoyer ses fichiers sur le réseau. :D

J'espère que ça va marcher mais logiquement oui.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Excellium le Juillet 24, 2014, 09:16:11 pm
Pourquoi envoyer des entités complexes via le réseau ? Du client vers le serveur y'a juste des entrées (clavier/souris/joystick) à envoyer, et du serveur au client les positions des entités, non ?
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Juillet 25, 2014, 03:59:49 pm
Salut.
Pendant la connexion j'envoie juste la position des joueurs et des ennemis oui.

Mais bon comme la map est côté serveur, j'envoie la map du serveur vers le client au tout début de la connexion.

Bref je suis revenu à un mode sans sérialisation finalement pour transférer la map du serveur vers le client. (Moins galère en c++)

Mon essai avec la sérialisation ne fonctionne tout simplement pas. :/ (En tout cas y'a plus rien qui s'affichait côté client)
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Excellium le Juillet 25, 2014, 09:42:58 pm
Tu ne peux pas fournir les maps avec le client, puis simplement vérifier leur intégrité via des checksum (envoyés au serveur pour qu'il les compare) ?
Si tes maps évoluent tu fais faire une MAJ aux clients.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Juillet 25, 2014, 10:05:11 pm
J'aurai pu faire ça aussi oui. ^^

Ceci dit, là, j'ai une IA à faire et un gameplay à finir afin de finaliser la version bêta du moteur.
Titre: Nouvelle fonctionnalité puissante à venir!
Posté par: Lolilolight le Juillet 26, 2014, 12:42:46 pm
Les clients de jeux sont souvent lourd, et font souvent plusieurs gigas en comptant les images, les sons, etc...

Eh bah ça ça ne sera pas le cas avec odfaeg! (Toutes les ressources pourront être chargée qu'une seule fois par l'éditeur de map, pour ensuite être transférée au serveur et puis au client dès lors du chargement de la connexion d'un joueur!)
Le joueur n'aura donc qu'à télécharge, le code source du client.
Tout le reste, sera récupéré via le serveur au chargement de la map. (A part peut être les musiques qui elles, ne peuvent pas être chargée en une seule fois à cause de leur taille trop grande)

Toutes les ressources seront serializable c'est à dire que vous pourrez les sauvegardez soit dans un fichier ou un flux en mémoire pour les envoyer d'une machine à l'autre par exemple.

Voici un exemple de code source qui sauvegarde un terrain dans un fichier (texture comprise) :

int main(int argc, char* args[])
{

    sf::VideoMode mode(800, 600);
    sf::ContextSettings settings(0, 0, 4, 3, 0);

    odfaeg::RenderWindow window(mode, "test", sf::Style::Default, settings);
    odfaeg::Texture tex;
    tex.loadFromFile("tilesets/herbe.png");
    odfaeg::g2d::Tile tile (&tex, odfaeg::Vec3f(0, 0, 0), odfaeg::Vec3f(120, 60, 0), sf::IntRect(0, 0, 100, 50));
    odfaeg::g2d::Entity* bt = new odfaeg::g2d::BigTile (odfaeg::Vec3f(0, 0, 0));
    bt->addChild(&tile);
    std::ofstream ofs("FichierDeSerialisation.tex");
    {
        boost::archive::text_oarchive oa(ofs);
        oa<<bt;
    }
    ofs.close();
    std::ifstream ifs("FichierDeSerialisation.tex");
    {
        boost::archive::text_iarchive ia(ifs);
        ia>>bt;
    }
    ifs.close();
    while (window.isOpen()) {
        sf::Event event;
        while(window.pollEvent(event)) {
            if (event.type == sf::Event::Closed) {
               window.close();
            }
        }
        window.draw(*bt);
        window.display();
        window.clear();
    }
    delete bt;
    return 0;
 

Ici je le fait dans un seule et même programme mais on pourrait très bien sauver le terrain et le recharger plus tard.

Ceci est une grande simplification de mon système complexe ou je devais sauvegarder tout des ids vers les textures, envoyer tout les attributs et la taille des vecteurs à la main, sans que ceux-ci soient compressés.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Laurent le Juillet 26, 2014, 02:08:42 pm
Et c'est quoi l'avantage de télécharger toutes les ressources au fur et à mesure quand on joue, plutôt que de télécharger et installer l'ensemble d'un coup ?
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Juillet 26, 2014, 04:45:00 pm
Moins long à télécharger le client, hum, je télécharge pas au fur et à mesure qu'on joue, je télécharge seulement à chaque connexion, bref... (ou à chaque changement de map)

Je pensais que ça serait trop lent à charger la map en faisant ça mais non ça va.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: G. le Juillet 26, 2014, 11:03:09 pm
En gros au lieu de télécharger le jeu une fois pour toute, tu le télécharges et le retélécharges à chaque fois ?  ???
Faut obligatoirement une connexion quand tu joues aussi ?
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Excellium le Juillet 27, 2014, 01:04:04 am
A la limite si c'était pour faire une sorte de streaming à la minecraft ça se comprendrait, mais la t'es juste motivé par faire un client léger, pour 0 intérêt...
Lis la première partie de la phrase de ma signature.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Juillet 27, 2014, 11:10:05 am
Au pire j'envoie les fichiers au client avec toutes les données (textures, entités du jeux, etc....) une seule fois et je fais un check sum, ainsi, pas besoin de retélécharger à chaque fois, ça me fera un client légé avec des données compressées et vérifiée par le serveur.

Oui je pense que je vais faire ça, ça réglera les problèmes de confidentialité, d'intégrité et de lenteur.

Boost à l'air de bien marcher pour archiver les données sauf dans les cas complexe. (Si j'ai une classe C qui hérite d'une classe B et une classe B qui hérite d'une classe A)

Il y a peut être d'autres librairies pour faire ça mais je les connais pas.

Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Août 04, 2014, 11:45:23 pm
Je pense que je vais recoder ça en python, j'ai vu le tutoriel de Laurent (justement) sur le site développez.com et j'ai vu que la métha programmation avec les typlelists c'était..., assez crade (avec les macros), j'ai essayer un autre code mais, ça me renvoie toujours un pointeurs sur l'objet de base!

template <typename B>
class DynamicTupleBaseElement {
  public :
      DynamicTupleBaseElement() {

      }
      virtual B get() const = 0;
};
template<typename E, typename B>
class DynamicTupleElement : public DynamicTupleBaseElement<B> {
    public :
    DynamicTupleElement(E element) {
        this->element = element;
    }
    E get() const override {
        std::cout<<"get derived element"<<std::endl;
       return element;
    }
    E element;
};
template <typename B>
class DynamicTuple {
    private :
    typename std::map<std::string, DynamicTupleBaseElement<B>*>::iterator f (std::string type) {
        return elements.find(type);
    }
    std::map<std::string, DynamicTupleBaseElement<B>*> elements;
    public :
    template <typename E>
    void addElement (std::string type, E element) {
        DynamicTupleBaseElement<B>* base_element = new DynamicTupleElement<E, B>(element);
        elements[type] = base_element;
    }
    template <typename E>
    bool exists (E element) {
        typename std::map<std::string, DynamicTupleBaseElement<B>*>::iterator it;
        for (it = elements.begin(); it != elements.end(); it++) {
            if (std::is_same<decltype(it->second->get()), E>::value)
                return true;
        }
        return false;
    }
    template <typename E>
    std::string getType(E element) {
        typename std::map<std::string, DynamicTupleBaseElement<B>*>::iterator it;
        for (it = elements.begin(); it != elements.end(); it++) {
            if (std::is_same<decltype(it->second->get()), E>::value)
                return it->first;
        }
    }
    auto get(std::string type) -> decltype(this->f(type)->second->get()) {
        std::cout<<"get : "<<typeid(decltype(this->f(type)->second->get()))
        .name()<<std::endl;
        return elements[type]->get();
    }
};
 

Il me recréer une surcharge avec B get() dans la classe dynamictupleelement et il me cast l'objet de type e en un objet de type b hors c'est pas ce que je veux.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Août 07, 2014, 10:08:19 am
Non en fait ça ne sera pas nécessaire de passer à python finalement j'ai trouvé une autre méthode pour sérialiser des entités dans un centenaire c'est juste qu'il me faut faire un dynamic_cast mais je n'ai pas le choix je suis obligé car en c++ il est impossible de récupérer le type réel d'un objet polymorphique ne compilation bref.

Ceci dis si j'ai le temps je ferai peut être un binding vers d'autres languages du framework tout comme le fait SFML.  :)
 
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Août 14, 2014, 07:33:05 pm
J'ai commencé à faire mon propre système de sérialisation, finalement avec le c++11 ce n'est pas si compliqué grâce aux tuples, et aux "type_traits", voici un tutoriel :
http://linor.fr/tutoriaux/tuto-723-la-serialization-et-la-compression-de-donnees-avec-odfaeg.php (http://linor.fr/tutoriaux/tuto-723-la-serialization-et-la-compression-de-donnees-avec-odfaeg.php)

J'ai mis à jour ça sur le git-hub, merci les tuples et les macros.  :D

PS : j'en ai aussi profité pour inclure un algorithme de compression que j'ai trouvé sur un site web.


Titre: Passage de la librairie en "header only" prochainement.
Posté par: Lolilolight le Août 19, 2014, 07:02:19 pm
Re, hum..., j'ai quelques soucis actuellement avec les objets polymorphique qui en utilise d'autres, si je change la définition d'une classe de la librairie en compilation à l'aide d'une macro, je dois forcément recompiler la librairie sinon ça crash. (Car lé définition de la classe ne correspond plus avec ce qu'il y a dans le fichier .a.

Mais je veux garder le côté "méta-programmation" qu'offre le c++11 et que je trouve très pratique (ça m'évite de devoir passé par un système de réflexion et c'est plus rapide à l'exécution)

Par exemple lors de la sérialisation, si je décide de rajouter une classe dérivée à une classe de base je change la définition du wrapper du fichier .h de la librairie en redéfinissant une macro de la librairie dans mon projet utilisant la librairie. (Exactement comme le fait boost)

Je pense que la seule solution pour éviter d'avoir un crash est de rendre ma librairie "header only". (Ainsi si je modifie la définition de la classe, pas besoin de recompiler toute la librairie! (Ou bien de modifier le header de la librairie à la main)
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: TheKingArthur le Août 29, 2014, 04:27:36 pm
Les liens vers ton github ou ton dev-blog sont morts.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Août 31, 2014, 08:23:26 am
Ha oui c'est vrai, j'ai update les liens, merci de me l'avoir signalé!

J'ai changé mon système pour la sérialisation, car, mon précédent système causait trop de problème à cause des forward déclarations.

J'en ai profiter pour faire "un genre" de système de réflexion, et je dis bien un "genre" car n'ayant pas de système de réflexion intégré dans le language comme en java, je dois enregistrer les types et les fonctions à la main.

Il y a peut être moyen de le faire automatiquement mais je ne connais pas la technique.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: msteve le Septembre 03, 2014, 10:44:07 am
images, vidéo ?
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Septembre 11, 2014, 09:10:15 pm
Je n'en met pas maintenant, j'ai des choses plus urgentes à faire pour la bibliothèque : réorganisation des fichiers, génération de la docs et finir de commenter le code source, et le site web afin de faire une librairie digne de son nom tout comme SFML. (Et réorganisation du répertoire git-hub pour un meilleur usage)

J'en ai aussi profiter pour utiliser std::function les outils pour la gestion automatique de la mémoire.

Je mettrai à jour le git-hub quand j'aurai fini. (juste avant de commencer le site web)

De plus je dois m'arranger aussi pour le nom de domaine avec une connaissance du web.

Donc vous comprenez bien que j'ai trop de boulot pour encore faire des vidéos ou bien des images.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Septembre 27, 2014, 12:56:12 pm
Je voudrais réagir suite à une remarque qui a été faîtes sur le forum Anglais au sujet d'une ombre. (celle d'un mur)

Je viens juste d'ajouter la possibilité de pouvoir changer le type d'ombre pour les murs, pour les murs qui se suivent donc j'utilise des shapes pour afficher les ombres, pour les murs qui ne se suivent pas, (comme l'unique mur près du feu de bois qui paraissait étrange), j'utilise un sf::Sprite ce qui rend beaucoup mieux!

On a donc maintenant le choix pour les modèles lors la génération d'une sf::Shape pour l'ombre ou bien d'un sf::Sprite.
Wall* w = new odfaeg::g2d::Wall(3, 80, t,odfaeg::g2d::AmbientLight::getAmbientLight(), odfaeg::g2d::Shadow::SHADOW_TYPE::SHADOW_TILE);
 
Je vais update le git-hub dès que possible, ici je suis entrain de mettre des commentaires partout pour générer la doc et ensuite je séparerai le code du mieux que je peux et je dois aussi rendre le linkage dynamique fonctionnel, et enfin je pourrai poster plus de vidéos!
J'essaye d'utiliser RAII et std::function le plus possible, et j'ai changé complètement ma classe FastDelegate. (Suite aux remarques qui ont été faîtes sur le forum Anglais à se sujet)
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Janvier 19, 2015, 09:11:34 pm
Sortie de la release 1.0 et optimisations pour la version pro.

Quelques nouvelles :

Le moteur va devenir payant, cependant le code source de la version 1.0 restera disponible sur la plateforme git mais risque de ne pas bien fonctionné pour les rendus plus complexe et ne sera plus maintenu.

Objectif de la version payante ?

L'optimisation, et l'amélioration des rendus, en effet :

La version actuelle utilise beaucoup de shaders, le FPS est bas, et les shaders dépendent de la compatibilité avec la carte graphique. :/

Lors de la version pro je compte faire tout les calculs ainsi que toutes les textures de rendus avec le CPU.
Mais on pourra bien sûr encore utiliser le GPU, pour afficher le framebuffer dans une fenêtre SFML par exemple ou bien SDL.

La version pro vise un rendu complexe en peu de temps, donc, le moteur utilisera son propre système de rasterisation, ainsi, plus besoin de récupérer le pixel dans un shader avec une texture de rendu et de faire pleins de if.

En effet, le moteur positionnera la vue à la position des lumières pour générer les ombres pour les fragments qui sont dans le champs de vision de la caméra et convertira les coordonnées des fragments de la vue de la lumière à la vue de la caméra pour les ombres. (Chose qu'il est plus difficile de faire avec les textures de rendu)

Le moteur gérera aussi la réfraction (effet de miroir) et la disfraction de la lumière.

PS : par contre je ne sais pas si il est possible d'afficher une image directement sur la fenêtre avec SFML, au pire, j'afficherai la framebuffer avec un sprite dans la fenêtre.

L'avantage de se système : aucune connaissance de openg, de la SFML ou bien de la SDL sera requise, juste une connaissance du langage c++.
Le moteur sera compatible peu importe la plateforme utilisée.
Le moteur permettra de faire de beau rendu en peu de temps (aussi possible avec opengl mais plus compliqué car nécessite d'avoir une très bonne connaissance d'opengl et un driver qui supporte les versions modernes de opengl (je n'ai pas cette version))

Le framework va aussi bien sûr changer de nom.

Voici un aperçu de ce que le framework sera capable d'afficher :

http://www.massal.net/article/raytrace/page5.html (http://www.massal.net/article/raytrace/page5.html)
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: G. le Janvier 19, 2015, 10:09:54 pm
C'est le début de la richesse !!! :D
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Janvier 23, 2015, 08:48:33 pm
Bon, ce n'est que le début parce que là j'ai juste de quoi avoir maison et voiture à 26 ans avec quelques loisirs en plus quand même.

Bon, je vise plus haut après bien sûr, car il me faut un garde du corps, une limousine, une maison de luxe comme celle du développeur de mine craft et tant que je suis dans mon délire et que je me lâche, pourquoi pas ma 1ère petite copine!!! é_é  :D (Après 5 ans de pur développement à développez pendant 11 heures par jour derrière un fichu PC)

Haaaa si seulement la vie était si belle!!!

Laurent Gomilla sera tellement jaloux qu'il va encore plus me troll avec ses messages du genre : "Met un code minimal" ou bien fermera encore mes topiques parce que ça part en sucette. :o

Non mais plus sérieusement, ça coûte la peau des fesses en Belgique, parfois je me demande, pourquoi je ne me retrouve pas à la rue ? :o

Le seul avantage c'est que les soins sont remboursé mais maintenant c'est devenu partout pareil surtout avec OBAMA.

Voici quelque vidéos  pour les rendus :

Ici (https://www.youtube.com/watch?v=ScJa2ZaKYQk)

Ici (https://www.youtube.com/watch?v=ScJa2ZaKYQk)

Et ici en 3D. (https://www.youtube.com/watch?v=Gd4cT8Noa7Q)

A venir, les 1er jeux (enfin), mais je suis encore un petit peu loin de la version commerciale pour parler de richesse, car, il me faut encore faire un site de vente en ligne dans un 1er temps ensuite bien sûr, terminer d'ajouter les dernières fonctionnalités du moteur en priant pour qu'il se vende, et pour avoir ainsi assez pour héberger les futurs projets commerciaux. :o

Et comme je dois me charger de tout ça tout seul, c'est pas pour demain.

Mais a 30 ans j'espère!







Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: victorlevasseur le Janvier 25, 2015, 03:12:20 pm
Faire les rendus avec le CPU c'est pas une bonne idée,ça va être super lent non ?
Titre: Re : [ODFAEG] Version 1.1 Sortie!
Posté par: Lolilolight le Janvier 27, 2015, 04:53:24 pm
Oui, c'est trop lent avec le CPU, mais pour la version pro je vais quand même faire un système de raytracing au niveau du CPU mais cela servira juste pour créer des logiciels d'imageries. (Car c'est trop lent pour les jeux vidéos)

Par contre j'ai effectué toutes les transformations au niveau du CPU (avec du batching) et désormais je n'effectue qu'un seul appel à draw pour un ensemble de tiles utilisant les même matériaux!
J'ai également optimisé mon algorithme de frustrum culling.

Je passe donc d'un FPS de 15-20 à 30-40 avec les shaders, et 60 sans shaders.

Bref c'est beaucoup plus rapide que avec SFML qui effectue les transformations au niveau du GPU.

Bref mon FPS double je passe de 15-20 à 30-40 FPS :

Ici (https://www.youtube.com/watch?v=oQm-W5Y04ss&feature=youtu.be)
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: G. le Janvier 27, 2015, 11:41:48 pm
Mais 30 FPS avec 2 lumières, c'est un peu de la merde non ?  ???
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Février 02, 2015, 11:58:52 am
Je peux en mettre plus ça ne changera rien, le moteur est en "biased raytracing", donc, j'effectue tout les calculs au niveau du GPU.
A partir du moment ou j'utilise des shaders le FPS descend, mais le driver opensource est plus lent..., d'après ce que j'ai lu, sur un driver propriétaire peut être que cela tournerais à 60 FPS surtout que j'effectue du dereffered shading. (C'est à dire que je calcule la lumière seulement dans la zone d'influence de la lumière)

C'est à dire en jouant avec les coordonnées de texture et en projetant des rayons entre le centre de mes lumières et les fragments de la scene.

PS : maintenant un rendu basique de lumière sans shaders avec juste du blending ça aura un FPS plus élevé oui, et pour la 2D je peux comprendre qu'un tel FPS paraisse nul, par contre pour le bumpmapping, le normalmapping, la réfraction et la composante spéculaire, un shader c'est obligatoire. :/

Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Mars 14, 2015, 10:14:12 am
Pour cause de bugs SFML (bien que il y en avec SDL2 aussi), j'ai décidé de faire une interface qui permettra de choisir entre SDL ou bien SFML pour le fenêtrage.

SDL_Init(SDL_INIT_VIDEO);
    SDLRenderWindow window(800, 600, "SDL Render window", sf::ContextSettings(0, 0, 4, 3, 0));
    RectangleShape shape(Vec2f(100, 50));
    while (window.isOpen()) {
        window.clear();
        window.draw(shape);
        window.display();
        SDL_Event event;
        while (window.pollEvent(event)) {
            if (event.type == SDL_QUIT) {
                window.close();
            }
        }
    }
    SDL_Quit();
    return 0;
 

Bien sûr, au niveau de l'application il faudra choisir quel librairie utiliser.

SDL s'en sort mieux également au niveau du multi-threading et de la gestion multi-fenêtre/multi-écran, mais je n'ai pas encore testé avec les textures de rendus et les shaders.

PS : Les events ne seront plus de type sf::Event mais de type IEvent, et lors de la création de l'application il y aura une interface commune de type IRenderWindow quis ervira pour les fenêtres SFML et SDL.
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Laurent le Mars 14, 2015, 11:35:23 am
Dans ce cas quel est l'intérêt de garder SFML ? Ca fait au moins 3 fois que tu dis que tu vas passer à SDL, fais le une bonne fois pour toute et tu seras tranquille...
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Mars 14, 2015, 02:24:36 pm
Citer
Dans ce cas quel est l'intérêt de garder SFML ? Ca fait au moins 3 fois que tu dis que tu vas passer à SDL, fais le une bonne fois pour toute et tu seras tranquille...

Il y a encore des développeurs qui adore SFML car il la trouve plus simple à prendre en main que la SDL, donc, je pense que pouvoir choisir entre les deux, n'est pas une si mauvaise idée.

Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: mazertys17 le Mars 14, 2015, 03:24:41 pm
Salut.

Je m'invite un peu dans le débat, mais, ayant essayé la SDL et la SFML, je peux témoigner, ( bien que je sois débutant ), et pour moi, il y a pas photo  ;).
La SFML, est non seulement, en effet, bien plus pratique à prendre en main, mais en plus, plus efficace en performance ( d'après des test qui ont été fait il me semble ).
Il y a une documentation très propre et clair pour travailler, chose moins évidente avec la SDL.
Une communauté active qui permet d'avancer plus rapidement et de faire face a des pbs.
Enfin, la SFML est très complète et permet de faire tout ce qui est nécessaire pour la créatiation d'apli comme le jeu vidéo.

Alors pourquoi vouloir mélanger 2 bibliothèques qui proposent la même chose..?
C'est probablement des complications pour pas grand chose...( mais bon c'est mon avis de débutant ).
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Mars 14, 2015, 06:57:58 pm
Je ne suis pas sûr que SDL soit faîtes pour faire du c++, ni optimisée pour, car, dès que j'essaye d'encapsuler les fonctions de la SDL dans des classes je me retrouve avec une fenêtre qui ne s’efface pas.

SFML marche bien à partir du moment ou tu n'as pas trop de fenêtre et surtout de fenêtre invisible. :/ (Avec X11 en tout cas)

Je galère à faire mon jeux à cause de ça. :/

Si je dois recoder un module fenêtre j'en ferai un mais vraiment très simple, avec juste la création de fenêtre x11.

PS : et oui au niveau de la communauté aussi c'est cela qui m'a fait vraiment hésiter plusieurs fois entre SFML et SDL et comme le dis Laurent ça fait trois fois que je dis que je vais passer à la SDL. XD

Et encore, ce n'est que des petits libs SDL et SFML pour faire des applications basique donc imagine ce que ça doit être lorsque j'utilise des frameworks plus conséquent. XD
Titre: Re : Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: G. le Mars 14, 2015, 09:57:08 pm
Citer
Dans ce cas quel est l'intérêt de garder SFML ? Ca fait au moins 3 fois que tu dis que tu vas passer à SDL, fais le une bonne fois pour toute et tu seras tranquille...

Il y a encore des développeurs qui adore SFML car il la trouve plus simple à prendre en main que la SDL, donc, je pense que pouvoir choisir entre les deux, n'est pas une si mauvaise idée.
Dans le cas improbable où un jour quelqu'un utilise ta bouse, il utilisera tes interfaces et pas la SFML ou la SDL non ?
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Mars 15, 2015, 09:20:28 pm
Malgré cela :
Citer
Dans le cas improbable où un jour quelqu'un utilise ta bouse, il utilisera tes interfaces et pas la SFML ou la SDL non ?

Oui, il pourra utiliser mes interfaces, mais il ne sera pas obligé de le faire!

Cela dépend à quel niveau il veut travailler. (Au niveau du framework lui même ou bien seulement au niveau de SFML ou bien de la SDL, ou bien tout autre librairie)

Car pour créer des plus petits jeux la couche d'abstraction n'est pas nécessaire.

M'enfin de toute façon, cela ne regarde que moi, vu que personne d'autre à ma connaissance n'utilise mon framework, je le fais juste pour me simplifier la vie...

Mais je pense que il y en a quand même qui me suivent vu que j'ai quelque visite sur ma page facebook, bref...
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: TheYoungGeek43 le Juillet 11, 2015, 12:25:45 am
Bonjour,
J'ai vus se projet et il m'allair bien j'ai survolé le topic et je souhaiterais savoir où vous en êtes de se projet qui vas beaucoup servir je pense
Titre: Re : [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: Lolilolight le Octobre 22, 2016, 05:44:30 pm
Le framework à un site web, n'hésitez pas à aller lire la documentation :

Ici (http://laurentduroisin.github.io/ODFAEG/)
Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: lo7601 le Janvier 03, 2019, 10:47:13 pm
Je cloture ce topique odfaeg ne sera plus un projet SFML car SFML ne fonctionne pas avec ODFAEG je vais essayé une autre librairie SDL pour le fenêtrage et pour le réseau je vais voir du côté de boost asio. 
Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: G. le Janvier 03, 2019, 10:56:44 pm
Un vrai sketch. ::)
Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: lo7601 le Janvier 06, 2019, 11:41:24 pm
Lol non j'ai dis une bêtise ça remarche avec SFML mais j'ai eu quelque crash à un moment donné que je n'avais pas eu avant lors de la création d'une fenêtre par exemple. (crash lors du partage du contexte opengl)
Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: lo7601 le Janvier 12, 2019, 10:06:09 pm
Salut, je l'ai sans doute déjà dit mais SFML ne permet pas de faire grand chose, le développeur c'est juste contenté de faire des abstractions sur des petites libs mais ce n'est pas assez pour créer un jeux. J'ai alors essayé plusieurs moteurs de jeux existant mais je n'étais toujours pas satisfait alors j'ai décidé de créer mon propre moteur. Pour ne pas devoir recoder tout les modules j'ai décidé qu'il serait bien de reprendre les classes de la SFML comme base, mais ODFAEG permet de faire beaucoup plus de choses que SFML car c'est une surcouche de SFML, ODFAEG permet de :

-Faire du "sprite batching".
-Afficher des tiles semi-transparentes dans n'importe quel ordre.
-Afficher des ombres mais pour l'instant ODFAEG ne génère les ombres que à partir de la lumière ambiante. (Celle du soleil)
-Afficher des lumières mais pour l'instant seul les lumières ponctuelles sont gérées.
-Ajouter les objets dans un contenaire spécial et récupérer uniquement ce qui se trouve dans la vue.
-Affichage d'animations pour l'instant seul la méthode d'affichage des animations frame par frame est gérée.
-Envoyé et recevoir des messages sur le réseau de manière chiffrée.
-Récupérer le chemin d'un point A vers un point B.
-Ajouter un volume de collision à chaque objet.
-Dessiner des guis.
-Sauvegarder et lire des objets dans un fichier sans se soucier de la structure du fichier grâce à la sérialisation.
-Créer des évènements personnalisés grâce au système d'actions, de trigger et de slot.
-Afficher de la 3D et manipuler une vue 3D.
-Et encore pleins d'autres choses que je n'ai pas citées.


Par contre je ne gère pas encore la réfraction, ni l'importation de modèles 3D.

Malheureusement avant de continué le développement du framework et du futur jeux j'ai trouvé qu'il manque quelque chose au moteur pour qu'il équivale les moteurs de jeux récents tels que unity ou encore unreal engine : une interface graphique.
Et je suis justement entrain d'en faire une!
L'interface graphique du moteur ODFAEG s'appellera ODFAEG Creator.
Je pourrai déjà posté quelques vidéos de l'avancement du jeux, et de l'interface graphique mais, je trouve que c'est encore trop tôt.
Par contre il y a un gros bémol, mes shaders ne fonctionnent pas sous windows, pourtant je n'ai pas d'erreur de compilation de mes shaders sous windows et j'ai eu énormément de mal à compiler le moteur sous windows. (CMake ne supportais pas les accents, headers de la librairies openssl non trouvés hors que j'ai bien spécifié à CMake le dossier dans lequel il sont, etc..., etc...)
J'ai été déçu, je pensais pouvoir utiliser l'openGL moderne dans le moteur mais..., j'ai été aussi déçu d'apprendre que mon driver graphique sous windows ne supporte que opengl 4.1 et pas opengl 4.2 j'aurais voulu essayé imageLoadStore mais il parait que c'est lent, alors pour l'instant je continue le développement sous linux et je verrai après ce que je peux faire sous windows pour que ça marche aussi, l'affichage.






Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: G. le Janvier 12, 2019, 11:02:32 pm
J'imagine que puisqu'ODFAEG permet de créer des GUI tu utiliseras ODFAEG pour créer ODFAEG Creator ?
Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: lo7601 le Janvier 13, 2019, 12:00:07 am
Citer
J'imagine que puisqu'ODFAEG permet de créer des GUI tu utiliseras ODFAEG pour créer ODFAEG Creator ?
Oui!
Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: nagimar le Juillet 15, 2021, 12:07:09 pm
Salut! Je n'ai pas donné de nouvelles depuis longtemps, mais il va y avoir beaucoup de changement au niveau de ce projet, en effet.

J'ai remarqué la lenteur de la SFML et on m'a clairement fait savoir que la SFML n'était clairement pas une référence pour utiliser opengl de manière performante pour de gros projets. On m'a également dit que la création d'un contexte opengl par texture de rendu n'est pas une bonne solution qu'il valait mieux n'utiliser qu'un seul contexte. (Bien que dans un contexte multithread ou pour créer plusieurs fenêtre pas le choix, mais dans le cas du multithreading on m'a conseillé d'utiliser VULKAN)

Et je vais avoir besoin du multithreading pour faire plusieurs rendus hors écran simultanément (SFML ne le fait pas par défaut) en même temps, car, les appels à glDraw pour toutes mes textures de rendu sont lent, même si j'utilise le bindless texturing et les buffers pour ne faire qu'un seul appel à glDraw par texture de rendu.

Autre chose qui ralenti (mais côté CPU ici) ce sont les fonctions virtuelles, en effets, la recherche de la bonne fonction à appeler se fait à l'exécution et la SFML utilise des fonctions virtuelles.

J'ai alors réfléchi à une autre solution, sans pour autant supprimer l'héritage parce que j'avais pensé à un système de type ECS mais dans ce cas je devrais récupérer les composants de transformations de toutes les entités enfants, les enfants des enfants, etc... et calculer la matrice de transformation finale combinée et également les positions relatives hors que avec l'héritage je peux faire ça automatiquement avec une méthode onMove par exemple que je redéfini, comme ça, tout se remet à jour automatiquement à chaque fois que j'appelle move, sinon je devrai le faire manuellement après chaque appel à move. (SFML ne possède pas de méthode onMove)

Alors j'ai recherché une solution pour pouvoir utiliser l'héritage sans utiliser de fonctions virtuelles comme le fait la SFML, et j'ai trouvé une solution, qui utilise les templates variadique et le polymorphisme d'inclusion.

J'ai testé ça dans la fonction main la rapidité et je me suis rendu compte que c'est vachement plus rapide (4 fois plus rapide) que d'utiliser des fonctions virtuelles comme le fait la SFML, en plus j'en utilise pas mal dans ODFAEG actuellement, ce qui ralenti.

La solution que j'ai trouvée est d'inclure chaque nouveau type dans un tuple, et générer une série de fonctions qui vont se charger d'appeler un foncteur, sur le bon type. (En faisant une vérification (SFINAE) sur le nombre d'arguments et le type des arguments dans le cas d'une surcharge de fonction pour pas que le compilateur râle parce qu'il ne trouve pas la fonction lors de l'appel)

Et à l'exécution il va choisir la bonne fonction à appeler suivant le type, au moyen de if, else..., le type n'est rien d'autre que la position du type dans le "parameter pack".

Voici un code qui montre ce que ça donne au niveau de l'utilisation, j'ai testé et, ça à l'air vraiment cool, comme le type du tuple change à l'exécution je ne peux pas le stocker dans une classe en tant que variable membre, mais je peux le créer et le passer à une fonction (la boucle de jeux) ce qui m'évite de devoir utiliser un global.



Je pense également à mettre les constructeurs en privé et utiliser une factory qui va se charger de gérer les variables globale, plutôt qu'utiliser des variables statiques qui pose problème lors de l'utilisation de plugin, vu que sur windows, elles ne sont pas partagées lors de l'appel du pointeur de fonction extrait de l'une dll.

struct transformable {
    template<typename D>
    void move() {
        static_cast<D&>(*this).onMove();
    }
};

struct entity : transformable {
    unsigned int containerIdx, childrenContainerIdx, type, childrenContainerType, id;
    static unsigned int nbEntities;
    std::string managerName;
    entity() : transformable () {
        id = nbEntities;
        nbEntities++;
    }
    template <typename D, typename EntityManager>
    auto addChild(EntityManager& em, D* entity) {
        auto newem = em.add(entity);
        return newem;
    }
    template <typename EntityManagerArray, typename D, typename... Args, size_t... Ints, class = typename std::enable_if<sizeof...(Args) == 3>::type>
    void operator()(EntityManagerArray& ema, D* entity, std::string f, std::tuple<Args...> args, std::index_sequence<Ints...>) {
        if (f == "move") {
            move(ema, entity, std::get<Ints>(args)...);
        }
    }
    template <typename R, typename EntityManagerArray, typename D, typename... Args, size_t... Ints, class = typename std::enable_if<sizeof...(Args) == 3>::type>
    void operator()(EntityManagerArray& ema, D* entity, std::string f, std::tuple<Args...> args, std::index_sequence<Ints...>, R& ret) {
        if (f == "move") {
            ret = move(ema, entity, std::get<Ints>(args)...);
        }
    }
    template <typename R, typename EntityManagerArray, typename D, typename... Args, size_t... Ints, class... E, class = typename std::enable_if<sizeof...(Args) == 0>::type>
    void operator()(EntityManagerArray& ema, D* entity, std::string f, std::tuple<Args...> args, std::index_sequence<Ints...>, R& ret) {
        if (f == "f") {
            ret = func();
        }
    }
    float func() {
        return 1.1f;
    }
    template <typename EntityManagerArray, typename D>
    bool move(EntityManagerArray& ema, D* entity, float x, float y, float z) {
        transformable::move<D>();
        auto tp = std::make_tuple(x, y, z);
        ema.apply(entity->childrenContainerType, entity->childrenContainerIdx, "move", tp);
        return true;
    }
    void onMove() {
    }
};

unsigned int entity::nbEntities = 0;



struct sphere : entity
{
  sphere() : entity() {

  }
  void onMove() {
      std::cout<<"update datas on sphere instance : "<<id<<" moved"<<std::endl;
  }

};
struct rectangle : entity
{
  rectangle() : entity() {

  }
  void onMove() {
      std::cout<<"update datas on rectangle instance : "<<entity::id<<" moved"<<std::endl;
  }
};
struct convexshape : entity
{
    convexshape() : entity() {

    }
    void onMove() {
        std::cout<<"update datas on convex shape instance : "<<entity::id<<" shape"<<std::endl;
    }
};
template <typename D>
struct appli {
    bool running = false;
    bool isRunning () {
        return running;
    }
    template<typename EntityManagerArray>
    void update(EntityManagerArray em) {

    }
    template<typename EntityManagerArray>
    void init(EntityManagerArray& em) {
        static_cast<D*>(this)->onInit(em);
    }
    template<typename EntityManagerArray>
    void exec(EntityManagerArray& ema) {
        if (!running) {
            running = true;
            init(ema);
        }
        while(running) {

            static_cast<D*>(this)->onExec(ema);
        }
    }

};
struct myappli : appli<myappli> {
    sphere sph;
    rectangle rect, rect2;
    convexshape shape, shape2;
    myappli() : appli<myappli>() {

    }
    template<typename ManagerArrayEntity>
    void onInit(ManagerArrayEntity& ema) {
        sph.managerName="entity managers";
        rect.managerName="entity managers";
        shape.managerName="entity managers";

        ::EntityManager<IEntityManager, entity> ems;
        //ems.name = "entity managers";
        ::EntityManager<IEntityManager, entity> childrenem;
        //childrenem.name = "sphere children manager";

        auto children0em = sph.addChild(childrenem, &rect2);
        auto children1em = sph.addChild(children0em, &shape2);
        children1em.name = "sphere children";
        auto em = ems.add(&shape).add(&rect).add(&sph);
        em.name = "entity managers";
        auto emas = ema.add(&em).add(&children1em);
        sph.childrenContainerIdx = children1em.containerIdx;
        sph.childrenContainerType = children1em.type;
        exec(emas);
    }
    template<typename ManagerEntityArray>
    void onExec(ManagerEntityArray& ema) {
        bool retb;
        auto tp = std::make_tuple(1.1f, 2.2f, 3.3f);
        ema.apply(0, 0, sph.type, sph.containerIdx, "move", tp, retb);
        float retf;
        auto tp2 = std::make_tuple();
        ema.apply(0, 0, sph.type, sph.containerIdx, "f", tp2, retf);
        std::cout<<"rets : "<<retb<<","<<retf<<std::endl;
        ema.apply(0, 0, rect.type, rect.containerIdx, "move", tp, retb);
        ema.apply(0, 0, shape.type, shape.containerIdx, "move", tp, retb);

    }
};

int main(int argc, char* argv[])
{    
    myappli appli;
    EntityManagerArray<IEntityManager> entityManagerArray;
    appli.exec(entityManagerArray);

 

De gros changements sont à venir donc..., je ne sais pas si ODFAEG va rester un projet SFML, mais en tout cas le design de la SFML va être remplacé. (Enfin tout dépendra de la rapidité de ce nouveau design à l'exécution lorsque je l'implémenterai dans le framework et surtout, si ça fonctionne pour tout mes projets utilisant le framework.)







Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: G. le Juillet 15, 2021, 10:20:47 pm
T'étais pas déjà passé 10 fois à SDL ?  :o ???
Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: nagimar le Juillet 16, 2021, 09:07:23 am
non, et puis de toute façon je possède une interface, je peux passer d'une lib à l'autre sans soucis si j'ai un problème avec SFML parce que par exemple SFML le module fenêtre de la SFML ne gère pas Vulkan, là je suis entrain de faire des tests pour voir ce qui est plus performant, je pense que un système sans polymorphisme est le plus performant car pas besoin de rechercher des types (enfin c'est ce qu'on m'a porposé de faire), cependant, pas de redéfinition de comportements possible donc plus lourd à mettre en œuvre et c'est ça qui est frustrant, qu'on utilise la POO et qu'au final on se rend compte que ...

Je vais quand même faire un benchmark pour voir si, ça vaut la peine de change le design du framework.


Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: nagimar le Juillet 17, 2021, 10:30:08 am
J'ai essayé plusieurs design de conception et je me suis rendu compte que au niveau des performances, le design actuel est celui qui convient le mieux.

Par contre j'ai des pertes de performances au niveau des draws calls. Je ne sais pas trop ce que je vais faire, utiliser plusieurs threads pour éliminer les goulots d'étranglement, comme je faisais avant, je les avais retiré parce que, une personne m'avait conseillé de le faire mais j'ai remarqué que il faut pas toujours écouter ce que les gens propose, surtout sans avoir fait de tests de performance.
Titre: Re: [ODFAEG] (Open Source Development Framework Adapted For Every Game)
Posté par: nagimar le Juillet 23, 2021, 10:00:10 pm
Salut à tous, ça y est j'ai enfin trouvé ou ça coïnce au niveau des performances!

https://quick-bench.com/q/jEGRWG62s39A0OzY22E-iNtuvWo (https://quick-bench.com/q/jEGRWG62s39A0OzY22E-iNtuvWo)

Je vais donc changer la conception du framework, il devrait être vachement plus rapide une fois cela de fait!
Je suis curieux de savoir ce que ça va donner au niveau du raytracing, qui pour l'instant, est beaucoup trop lent.