Bienvenue, Invité. Merci de vous connecter ou de vous inscrire. Avez-vous oublié d'activer ?

Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - Lolilolight

Pages: « Précédente 1 2 3 [4] 5 6 ... 53 Suivante »
46
Fenêtrage / Re : Traiter un type d'évènement en 1er.
« le: Avril 21, 2014, 08:48:39 pm »
Wai non oublie ce que j'ai dis il me semble que sf::Keyboard renvoie bien false au bon moment c'est juste que je dois dire à mon thread de ne pas traité les évènements keypressed en attente lorsque la touche a été relâchée.

47
Fenêtrage / Traiter un type d'évènement en 1er.
« le: Avril 21, 2014, 08:42:42 pm »
Salut.

J'ai fait un thread afin de traité les évènements SFML de manière assynchrone c'est à dire :

1)traité un évènement.
2)rendre la scène et traité un autre évènement simultanément.
Et ainsi de suite et donc je ne fait pas de boucle while qui traite tout les évènements puis qui effectue le rendu.

Le soucis c'est que, lorsque j'appuie sur une touche, il ne stope pas la commande au moment ou je relâche la touche, car pollevent me renvoie tout les évènements keypressed qui sont en attente de traitement par mon autre thread et seulement après il traite l'évènement keyreleased, il y a donc un décalage entre mes actions et le moment ou je relâche la touche, et la classe sf::Keyboard ne résoud pas le problème. :/ (Il me semble qu'elle ne renvoie faux que lorsque l'évènement keyreleased a été traité par pollEvent)

Alors j'aimerais récupérer en priorité les évènements de type keyreleased pour ignorer les événements keypressed en attente lorsque je relâche la touche pour arrêté l'action au moment ou je relâche la touche et pas 5 secondes après, est ce possible de faire ça avec SFML ?

Sinon j'aimerais implémenter ça moi même dans la classe sf::Window.

48
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.









49
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

50
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.

51
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. ;)

52
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.

53
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. ;)

54
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.


55
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.

56
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.


 

57
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)

58
Ok je vais regarder de ce côté là, merci. :)

59
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.

60
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.

Pages: « Précédente 1 2 3 [4] 5 6 ... 53 Suivante »