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 ... 53 Suivante »
31
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.  :)
 

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

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


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

35
Projets SFML / Nouvelle fonctionnalité puissante à venir!
« 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.

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

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

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

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

40
Voila j'ai terminé le réseau et le système de collision ce qui clôture la version 2 du framework!



Les collisions :



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

41
Discussions générales / Re : Forum français
« le: Juin 08, 2014, 11:27:44 am »
Forcer l'anglais ne serait pas plus mal...

Je trouve que le forum français n'est pas suffisant pour avoir des conseils, la plupart des discussions se font en effet du côté Anglais ce qui rend cette langue incontournable pour tout ce qui touche au domaine technique. (même si je ne suis pas parfais bilingue (voir trilingue même car je connais aussi du néerlandais mais pas l'Allemand. :X ) mais pas vraiment besoin l'Anglais technique se limite souvent à une centaines de mots)

Cela fera sans doute râler certains qui ne veulent pas apprendre l'anglais mais bon je ne pense pas qu'on y perdrait grand chose.

SDL on bien un seul forum en Anglais, et devoir présenter mon projet et faire des présentations dans plusieurs langues m'embête également. :/

(Les Allemand sont aussi pas mal présent dans le domaine du jeux vidéos et du multimedia, c'est surement dû à certaines sociétés comme par exemple blizzard)

42
Projets SFML / Re : Moteur graphique d'éclairage 2.5D
« le: Juin 07, 2014, 09:57:03 pm »
Ha justement je comptais essayer de faire un moteur d'éclairage par pixel en 2.5D pour mon framework car par vertex ce n'est pas toujours très beau. (en effet)

Pour la normal map ça va, pas de soucis, je vois comment faire j'ai pu généré automatiquement une heightmap et une normal map pour calculer l'éclairage des pixels via le multi-pass rendering.

Mais pour la projection des ombres (dans un shader) je sèche un petit peu et je n'ai plus aucune nouvelle de l'auteur du moteur donc, je pense que je vais regarder ton lien, merci.  :)

43
Projets SFML / Re : Projet d'extension de SFML. (SFML 3D)
« le: Mai 17, 2014, 01:00:15 pm »
Puisque il y en a qui m'ont posé la question, je tiens à préciser que j'ai inclus ce projet dans mon nouveau projet ODFAEG :
http://en.sfml-dev.org/forums/index.php?topic=13779.0


44
Projets SFML / Re : MoDern Console Core
« le: Avril 23, 2014, 09:35:57 am »
Si elle se ferme en release c'est que tu as du oublier de faire une genre de boucle while infinie pour laisser ta console ouverte.

while(true) {
      //Affichage de la console.
}
 

J'ai pas eu le temps de regarder plus que ça ton code encore mais je pense que le problème doit venir de là car en debug le programme tourne tout le temps, jusqu'à que tu stop le déboguer mais pas en release.

45
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. :)



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