OmbreNoire a écrit:

Par contre je ne sais pas ce que c'est les cache friendly faut que je regarde.

En gros:

-Grouper les données de même types ensembles
-Évité les petites allocations (new/malloc)
-Préférer la stack au lieu de la heap
-Évité les accès à des zone random dans la mémoire (pointeurs vers différentes zone)
-Préférer une copy de petits élément plutôt des des objets avec compteur (shared_ptr)
-Enlever tout code bloat
-Utilisé au maximum les constantes et les fonction inline pour déduire le type au compile time et réduire grandement les calculs
-Unroll des loops critique (#pragma unroll [(n)])

CWC utilise GDB par défaut, c'est normal que ce soit un petit peu plus lent (normalement on peu le désactiver, mais je crois avoir cassé quelque chose dernièrement XD )

-
Edité par Maeiky 23 novembre 2020 à 19:32:59

Ok, j'ai trouvé le bug de la réfraction map qui ne s'affichait pas correctement! 

Maintenant, reste plus qu'à tout oprimiser et se sera parfait, j'ai de l'eau avec de la réfraction, des lumières et des ombres, bref, je suis content!

EDIT : j'ai mit à jour la version d'assimp vers une version plus récente pour que le code de la classe qui importe des modèles 3D fonctionne.

-
Edité par OmbreNoire 24 novembre 2020 à 19:04:06

J'ai réfléchi sur les fonctionnalités de odfaegcreator et je pense que ça serait bien de faire comme unity et qtcreator. Grosse release donc à venir! L'utilisateur pourra créer :

Toutes entités ou interface graphique.

Il pourra passer une entité parent à une autre.

Il pourra attacher un script à  une entité odfaeg.

Il pourra paramétrer les entités ou interface graphique et si c'est par exemple un monstre il pourra définir une zone dans laquelle le monstre peu se balader ou attaquer comme dans unity.

Il pourra aussi créer des quêtes et des compétences qui seront stockées dans une base de données.

Par contre je ne sais pas si on peut appeler cwc en mode commande comme je le faisait avec gcc sur Linux.

Parce que j'aimerais faire un bouton compiler et puis exécuter. 

Bref il y a du boulot je ne sais pas si j'arriverai jusqu'au bout.

On dirait bien que ta repris de la motivation

OmbreNoire a écrit:

Par contre je ne sais pas si on peut appeler cwc en mode commande comme je le faisait avec gcc sur Linux.

Parce que j'aimerais faire un bouton compiler et puis exécuter.

Normalement oui, mais puisque j'ai très peu utilisé cette fonctionnalité, elle s'est retrouvé non fonctionnel avec le temps.

Je vais regarder pour arranger ça.

Bon j'ai corrigé un bug dans la classe RectangleShape. (la outline se "scalait" lorsque je changeais la taille du rectangle) 

La motivation est revenue!!! Surtout depuis que j'ai corrigé certains bugs, je me disais que je faisais de la merde et c'est vrai que ce moteur n'est pas encore au point, brouillon (du code que je n'utilise plus à certains endroit, du code non séparé à certains endroit dans des fichiers .h, pour le compiler ça n'a pas été facile non plus à cause de toutes les dépendances, etc...) et la performance pas top surtout lorsque l'on affiche la réfraction je pense que ça cale aussi au niveau du CPU.

Bref toutes ces raisons m'avaient démotivé à continuer mais je suis remotivé pour améliorer le moteur.

EDIT : par contre il y a un truc que je n'avais pas avant c'est du noir entre les textures du sol, je n'avais pas ça avant c'est depuis que j'ai update le driver.

EDIT 2 : non c'est depuis que j'avais mit la taille de la per pixel linked list a 5, je l'ai remise à 20 parce que plus besoin de renderdocs pour le moment.

EDIT 3 : j'ai trouvé la fonction qui ralentissait tout c'était celle-ci :

std::vector<Entity*> visibleReflEntities = World::getEntitiesInRect(reflectView.getViewVolume(), expression);

surtout que je l'appelais 6 fois, maintenant, je ne réfracte que les entités visibles, ça augmente le FPS, je passe de 16 à plus de 40.

-
Edité par OmbreNoire 25 novembre 2020 à 22:38:18

Hum ... depuis que tu as ajouté assimp ça ne fonctionne plus, car il manque "libassimp.dll" pour que l'application se lance.

Il faudrait que l’inclure dans:
"ODFAEG/extlibs/bin/x86/"

Oui, j'ai rajouté la dll manquante à la main dans les dossiers des exécutables, mais je ne l'ai pas rajouté dans le dossier ou cwc copie les .dll.

Finalement je ne pense pas faire de classe pour sauvegarder des compétences, objets ou monstres car ceux-ci peuvent avoir des attributs très différents en fonction du type de jeux par exemple pour le personnage il peut être stun pendant un certains temps ou un certain nombre de tours si c'est un jeux par tour, pour les items ils peuvent très bien booster les stats, ou donner tout type d'effets différents comme les cartes sur ragnarok par exemple et pour les compétences elles peuvent soigner ou faire des dégâts instantanés ou pendant un certains temps ou nombre de tours, bloquer un certains nombre de coup ou de dégâts, créer des objets, créer une zone sur la carte ou on est protégé des sorts de zone, etc..., etc..., bref, ça me semble difficile de créer une classe surtout que chacun de ses objets applique un comportement différent. Ce que je vais plutôt faire c'est définir un foncteur et lorsque le joueur utilisera tel objet ou compétence ça modifiera le comportement de la zone, du joueur ou autre.

L'IA peut varier suivant le type de jeux donc je préfère laisser l'utilisateur la coder lui même dans les scripts.

J'ai vu dans un tutoriel que sur unity tu as des objets prédéfinis pour les items avec des attributs mais je ne pense pas que ça soit une bonne chose car les attributs changent en fonction du type de jeux. A moins que l'on peut créer ses propres classes pour les items et définir un comportement différent ? Bref je ne connais pas très bien Unity.

EDIT : lorsque j'aurai terminé ODFAEG Creator j'essayerai de continuer le jeux et faire quelque chose de minimal comme le projet Naïca mais bon eux ils sont une équipe, moi je suis seul, donc, ça me prendra du temps.

-
Edité par OmbreNoire 27 novembre 2020 à 18:31:12

Bon j'ai compilé ODFAEG-SERVER, j'ai dû rajouté une lib pour la connection à mysql (mysqlcppconn) mais le programme crash lorsque j'appelle driver->connect et la version et le nom du driver me renvoient des trucs étranges. (0 pour la version major, 22 pour la version minor et le nom du driver est vide)

Ca, ça va être embêtant si je ne peux plus utiliser mysql.

Pourtant, avant, ça marchait, mais c'était il y a bien longtemps, je ne sais pas ce qu'ils ont modifié depuis mais...

Pas de std::mutex et companie on dirait avec cwc :

C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:366:13
 error: 'mutex' in namespace 'std' does not name a type
 static std::mutex* m_openssl_mutex = nullptr;
             ^~~~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:366:8:
note: 'std::mutex' is defined in header '<mutex>'; did you forget to '#include <mutex>'?
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:57:1:
+#include <mutex>
 #endif
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:366:8:
 static std::mutex* m_openssl_mutex = nullptr;
        ^~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc: In function 'void cdk::foundation::connection::detail::thread_setup()':
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:370:3:
error: 'm_openssl_mutex' was not declared in this scope
   m_openssl_mutex = new std::mutex[CRYPTO_num_locks()];
   ^~~~~~~~~~~~~~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:370:30
 error: 'mutex' in namespace 'std' does not name a type
   m_openssl_mutex = new std::mutex[CRYPTO_num_locks()];
                              ^~~~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:370:25
 note: 'std::mutex' is defined in header '<mutex>'; did you forget to '#include <mutex>'?
   m_openssl_mutex = new std::mutex[CRYPTO_num_locks()];
                         ^~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc: In function 'void cdk::foundation::connection::detail::thread_cleanup()':
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:375:12
 error: 'm_openssl_mutex' was not declared in this scope
   delete[] m_openssl_mutex;
            ^~~~~~~~~~~~~~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc: In function 'void cdk::foundation::connection::detail::locking_function(int, int, const char*, int)':
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:384:5:
error: 'm_openssl_mutex' was not declared in this scope
     m_openssl_mutex[n].lock();
     ^~~~~~~~~~~~~~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:388:5:
error: 'm_openssl_mutex' was not declared in this scope
     m_openssl_mutex[n].unlock();
     ^~~~~~~~~~~~~~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc: In function 'void cdk::foundation::connection::detail::id_function(CRYPTO_THREADID*)':
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:397:26
 error: 'thread' is not a member of 'std'
           std::hash<std::thread::id>()(std::this_thread::get_id())
                          ^~~~~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:397:26
 note: 'std::thread' is defined in header '<thread>'; did you forget to '#include <thread>'?
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:57:1:
+#include <thread>
 #endif
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:397:26
           std::hash<std::thread::id>()(std::this_thread::get_id())
                          ^~~~~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:397:26
 error: 'thread' is not a member of 'std'
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:397:26
 note: 'std::thread' is defined in header '<thread>'; did you forget to '#include <thread>'?
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:397:36
 error: template argument 1 is invalid
           std::hash<std::thread::id>()(std::this_thread::get_id())
                                    ^
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:397:45
 error: 'std::this_thread' has not been declared
           std::hash<std::thread::id>()(std::this_thread::get_id())
                                             ^~~~~~~~~~~
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc: In function 'int cdk::foundation::connection::detail::poll_one(cdk::foundation::connection::detail::Socket, cdk::foundation::connection::detail::Poll_mode, bool, uint64_t)':
C:\Users\Laurent\Downloads\mysql-connector-cpp-master\mysql-connector-cpp-master\cdk\foundation\socket_detail.cc:851:27
 warning: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas]
   DISABLE_WARNING_CDK(4548)
                           ^
cdk\foundation\CMakeFiles\cdk_foundation.dir\build.make:132: recipe for target 'cdk/foundation/CMakeFiles/cdk_foundation.dir/socket_detail.cc.obj' failed
mingw32-make[2]: *** [cdk/foundation/CMakeFiles/cdk_foundation.dir/socket_detail.cc.obj] Error 1
CMakeFiles\Makefile2:1063: recipe for target 'cdk/foundation/CMakeFiles/cdk_foundation.dir/all' failed
mingw32-make[1]: *** [cdk/foundation/CMakeFiles/cdk_foundation.dir/all] Error 2
Makefile:128: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

Pourtant ils sont dedans mutex thread et companie.

-
Edité par OmbreNoire 28 novembre 2020 à 2:07:56

Ton output vient de cmake et non cwc

note: 'std::mutex' is defined in header '<mutex>'; did you forget to '#include <mutex>'?

As-tu oublié d'inclure <mutex>?


Normalement oui, il y a les mutex, je peux te référer à quelques exemples fonctionnel:

https://github.com/Cwc-Lib/restclient-cpp
https://github.com/Cwc-Lib/leveldb
https://github.com/Cwc-Lib/nghttp2
https://github.com/Cwc-Lib/libssh2

Aussi n'oublie pas d'ajouter les dll pré-compilé, sinon ça va m'être plus difficile de suivre ton projet

Encore cmake qui ne trouve pas les fichiers #include. J'essayais de compiler le connecteur c++ de mysql avec cmake en debug pour voir ou ça crash mais ça ne marche pas...

Est-ce que tu as réellement besoin de mysqlcppconn? Parce que tu peux faire des requêtes SQL avec Curl

Voir aussi : https://github.com/Cwc-Lib/restclient-cpp

Sinon dans le pire des cas on pourrait build mysqlcppconn avec  Cwc.

Et comment je fais alors sans connecteur c++ à mysql pour récupérer les données des joueurs et de tout les autres objets dans le programme serveur ?

sql::Statement* stmt = con->createStatement();
                sql::ResultSet* result = stmt->executeQuery("SELECT NAME, PASSWORD FROM HEROES WHERE NAME = "+pseudo+";");
                while(result->next()) {
                    if (result->getString("PASSWORD") == pswd) {
                        SymEncPacket packet;
                        packet<<"IDOK";
                        user->sendTcpPacket(packet);
                        std::cout<<"connect"<<std::endl;
                        caracter = new Hero(user, "Sorrok", "Nagi", "M", "Map test", "Brain", "Green", "White","Normal","Novice", 1);

                        BoundingVolume* bb2 = new BoundingBox(caracter->getGlobalBounds().getPosition().x, caracter->getGlobalBounds().getPosition().y + caracter->getGlobalBounds().getSize().y * 0.4f, 0,
                        caracter->getGlobalBounds().getSize().x, caracter->getGlobalBounds().getSize().y * 0.25f, 0);
                        caracter->setCollisionVolume(bb2);
                        caracter->setCenter(Vec3f(0, 300, 300));
                        World::addEntity(caracter);
                    }
                }
                delete stmt;
                delete result;

je ne connais pas curl, j'ai essayé sqlapi mais j'ai cette erreur :

C:\Users\Laurent\Windows\cwcODFAEGSERVER/../Demos/ODFAEG-SERVER/application.cpp:19: undefined reference to `SAConnection::Connect(SAString const&, SAString const&, SAString const&, eSAClient, void ( cdecl*)(SAConnection&, eSAConnectionHandlerType))'

Bref, ça commence à me chauffer 2 jours que j'essaye de me connecter à la base de donnée avec du code c++ mais ça ne fonctionne pas.
Au pire je peux utiliser des fichiers mais ça va être galère pour faire des ids pointant vers d'autres objets, j'aurai voulu insérer tout les objets du jeux dans une BDD et les lire, ou alors je fais ça avec l'éditeur de niveau et j'utilise la sérialisation de ODFAEG, je pense que je vais faire comme ça parce que ça n'ira jamais sinon.

-
Edité par OmbreNoire 28 novembre 2020 à 16:51:15

Hum j'ai jamais vraiment jouer avec C++/SQL. Mais ceci serait peut-être une alternative :

https://www.troliver.com/?p=372

Pour passer des données du c++ vers une base de donnée et les récupérer en php ok mais c'est l'inverse que je veux faire, créer les données en php (ou bien avec le client mysql) et les récupérer dans le code c++ on sait faire ça avec CURL ?

Au pire je ferai avec des fichiers.

-
Edité par OmbreNoire 28 novembre 2020 à 18:47:32

Bon, étant donné que j'ai des crashs en exécutant ODFAEG-SERVER et ODFAEG-CLIENT en mode release avec cwc et que je n'avais pas tout ces crashs avant, en plus le déboguer de cwc ne m'indique rien, j'ai décidé d'essayé avec un autre compilateur (tdm-gcc) et de ne plus passer par cwc mais par cmake, j'ai réussi à compiler ODFAEG avec cmake. (j'ai trouvé pourquoi il ne trouvais pas les include)

Maintenant je dois encore lier toutes les dépendances de ODFAEG avec code::blocks pour chacun des projets pour tester, j'espère que ça ne crashera plus et si ça crash encore que le débuguer me donnera plus d'infos.

EDIT : bah ça ne crash plus donc je pense que le problème venait du compilateur utilisé par cwc.

-
Edité par OmbreNoire 29 novembre 2020 à 21:32:30

J'ai réfléchi un petit peu sur comment je pourrais faire pour réfracté une grande étendue d'eau, pour le bien, il faudrait placé la caméra à chaque tile d'eau et dessiné tout les objets autant de fois qu'il y a de tile d'eau mais ça ne serait pas optimal du tout, alors ce que j'ai fais, j'ai placé la caméra au centre de la grande étendue d'eau, j'ai fait un zoom si la taille de l'étendue de l'eau est plus grande que la fenêtre, le résultat est assez bizarre mais pas facile de faire ça correctement en 2.5D :

J'ai pensé au threads niveau optimisation mais je ne suis pas sûr que ça peut vraiment optimiser le code en plus :

-Il faut gérer les sessions critiques.

-Pendant qu'un mutex est lock les autres threads sont obligés d'attendre.

Maintenant j'ai lu qu'il y a le lock free programming mais je sais pas ce que ça peut donner au niveau optimisation, j'ai besoin d'avis.

Tu n'optimise pas avec des threads, tu sépare les tâches sur plusieurs processeur ce qui permet d'exploiter plus de ressources.

Le lock free programming est intéressant du point de vue que tu ne gaspille pas tes ressources à faire du spinlock.

La façon la plus simple est de faire des Worker thread avec un système de communication par AtomicQeue

J'ai laissé tombé les threads, j'ai trop d'accès concurrents à gérer et pas mal d'objets, j'étais entrain de réfléchir sur un éditeur de quêtes, monstres et autres objets, le problème c'est que les variables de ses objets peuvent varier suivant le type de jeux, alors j'ai pensé à faire en sorte que l'utilisateur puisse créer ses propres interface graphiques pour ensuite sauvegarder les valeurs des différents champs, d'un fichier qu'il pourra lire dans le jeux. Je ne pense pas qu'il y ai moyen de faire ça dans unity.

J'ai également laissé tombé les bases de données, je pense pas que j'en ai vraiment besoin (tout comme les threads), de plus, j'ai des crashs avec mysql connector c++ et sql api.

J'ai corrigé un bug pour l'origine pour la rotation qui n'était pas bonne.

Désormais on peut faire du scaling et des rotations dans odfaeg creator.

Mais je suis encore loin de quelque chose comme unity. (Enfin je veux pas recréer unity mais faire quelque chose de différent)

Il me reste encore à faire :

-Ajout de lumières.

-Collisions.

-Paramétrage de la matrice de transformation pour les ombres.

-Création de guis avec ODFAEG Creator.

-Mise à jour automatique des scripts.

-Création de scripts personnalisés pour des entités personnalisées.

-La sauvegarde du projet dans un fichier.

Et sûrement encore d'autres chose que j'ai oublié de cité.

EDIT : correction du bug du texte graphique qui ne s'affichait pas toujours bien.

-
Edité par OmbreNoire 5 décembre 2020 à 19:30:37

Ajout de la sauvegarde dans odfaeg creator je n'ai pas encore testé par contre.

J'ai testé une synchronisation du temps du client avec le serveur mais ce n'est pas très précis :

J'envoie une requête au client pour demander l'heure client.

for (it = clients.begin(); it != clients.end();it++) {
                        TcpSocket& client = **it;
                        User* user = Network::getUser(client);
                        if (user != nullptr && user->getRemotePortUDP()) {
                            Packet packet;
                            sf::Int64 lastSrvTime = core::Application::getTimeClk().getElapsedTime().asMicroseconds();
                            packet<<"GET_TIME*"+core::conversionLongString(lastSrvTime);
                            user->setLastSrvTime(lastSrvTime);
                            user->sendUdpPacket(packet);
                        }
                    }
                    Network::getTimeBtw2SyncClk().restart();

J'envoie l'heure client au serveur :

if (clientUDP.receive(packet, address, port) == Socket::Done) {
                            if (address == srvAddress) {
                                string message;
                                packet>>message;
                                if (message == "PING") {
                                    packet.clear();
                                    message = "PONG";
                                    packet<<message;
                                    Network::sendUdpPacket(packet);
                                } else if (message.find("GET_TIME") != std::string::npos) {
                                    packet.clear();
                                    sf::Int64 time = core::Application::getTimeClk().getElapsedTime().asMicroseconds();
                                    message = "SET_TIME*"+core::conversionLongString(time);
                                    packet<<message;
                                    Network::sendUdpPacket(packet);
                                } else {
                                    Network::addResponse(message);
                                }
                            }
                        }

Et côté serveur je met à jour l'heure client comme ceci :

if (udpSocket.receive(packet, sender, port) == Socket::Done) {
                            packet>>request;
                            User* user = Network::getUser(sender, port);
                            if (user != nullptr) {
                                std::vector<std::string> infos = core::split(request, "*");
                                if (infos[0] == "PONG") {
                                    user->addPingTime(user->getPingClock().getElapsedTime().asMicroseconds() * 0.5f);
                                } else if (infos[0] == "SET_TIME") {
                                    sf::Int64 cliTime = core::conversionStringLong(infos[1]);
                                    sf::Int64 srvTime = core::Application::getTimeClk().getElapsedTime().asMicroseconds();
                                    sf::Int64 syncTime = cliTime + (srvTime - user->getLastSrvTime()) * 0.5f;
                                    user->setClientTime(syncTime);
                                } else {
                                    Network::addRequest(user, request);
                                }
                            }
                        }

Et j'utilise cette fonction pour récupéré l'heure client :

void User::setLastSrvTime(sf::Int64 time) {
            lastSrvTime = time;
        }
        sf::Int64 User::getLastSrvTime () {
            return lastSrvTime;
        }
        void User::setClientTime(sf::Int64 time) {
            elapsedTime.restart();
            clientTime = time;
        }
        sf::Int64 User::getClientTime () {
            return clientTime + elapsedTime.getElapsedTime().asMicroseconds();
        }

Alors il faut faire attention avec cette fonction car elle n'est pas très précise en effet lorsque j'envoie un message du serveur avec le temps client et lorsque le client reçoit la requête et que je calcule le temps écoulé entre l'envoi et la réception de la requête :

sf::Int64 time = Application::getTimeClk().getElapsedTime().asMicroseconds() - conversionStringLong(infos[nb+1]);

J'ai parfois des temps négatifs. (Comme si le serveur à envoyé la requête après que le client la reçoit ce qui est impossible bien sûr)

Ceci est sans doute du à l'estimation ici :

sf::Int64 syncTime = cliTime + (srvTime - user->getLastSrvTime()) * 0.5f;

En faisant * 0.5 j'estime que le temps d'envoi est égal au temps de réception mais ceci est faux bien sûr. 

EDIT : j'ai passé le repository en private.

EDIT 2 : correction d'un bug d'affiche avec la classe BoneAnimation.

-
Edité par OmbreNoire 9 décembre 2020 à 1:14:31

J'avance dans ODFAEG Creator (création de systèmes de particule) mais j'ai passé le répo en privé car moi seul l'utilise, et je pense que je vais le vendre si jamais quelqu'un veut l'utiliser et du coup ça m'a retiré le site et le système de dons qui ne sert à rien pour le moment.

EDIT : j'ai réglé un bug, le texte ne s'affichait pas bien car j'avais pas unbind le PIXEL_UNPACK_BUFFER

EDIT 2 : j'ai rajouté la possibilité de désactiver le "scissor test" sur les Panel parce que il y a un bug lorsque je fais deux scissor test les onglets qui sont après l'onglet sélectionné sur le tabpane ne sont pas caché lorsque l'onglet sort du panneau. (Bref le scissor test ne marche plus lorsque je fais deux scissor test)

-
Edité par OmbreNoire 10 décembre 2020 à 21:59:45

J'ai commencé à implémenter les collisions dans ODFAEG Creator, j'ai eu énormément de mal à récupérer la cellule pointée par la souris parce que la vue bouge tandis que la grille non il fallait donc calculer la position de la cellule pointée en fonction de la position de la vue et de la taille de la cellule pour x et pour y.

J'ai modifié la classe Text pour ajouté une couleur de fond et la classe TextArea pour sélectionner du texte et déplacer le texte si le text est plus grand que la TextArea j'ai également appliqué un test pour ne pas afficher le texte lorsqu'il sort de la TextArea.

-
Edité par OmbreNoire 12 décembre 2020 à 15:15:39

Nouveautés à venir, un système d'introspection et la possibilité de compiler des fonctions et de les appeler pendant l'exécution!

Je pensais utilisé la librairie RTT mais elle ne compile pas donc je vais faire ça moi même, j'ai vu que ce n'était pas si compliqué que ça.

-
Edité par OmbreNoire 13 décembre 2020 à 21:19:53

Nouveauté! Runtime serialisation! (Créer et sauvegarder dynamiquement vos propres game objects avec ODFAEG Creator!)

Ca y est ça marche!

J'ai fais une interface graphique qui récupère toutes les classes et tout les constructeurs (après je ferai les fonctions membres) des scripts créés par l'utilisateur, l'utilisateur peut choisir la classe et le constructeur du gameobject qu'il veut créer, la gui affiche automatiquement tout les types des arguments du constructeur, l'utilisateur peut entrer les valeurs des paramètres et ensuite, lorsqu'il clique sur le bouton, l'objet est crée et sauvegardé dans un fichier!

Petite vidéo prochainement qui illustre le principe.

Et ça y est le système de sauvegarde de particules fonctionne!!! Ainsi que le système pour copié une entité sélectionnée.

J'ai corrigé un bug lors de la sérialisation d'objets, j'ai fait sauvegarde de copie et de pointeur et plus les références parce que j'avais deux std::string différente qui avaient la même adresse (le compilateur c++ donnait la même adresse lors de la réalocation) du coup ça plantait.

Je ne sais pas du tout comment utiliser std::reference_wrapper dans les classes ITextArchive et OTextArchive pour sauvegarder des références.

Je viens d'ajouté une fonction pou récupérer toutes les super classes d'une classe, mais, c'est la merde à faire en c++ pour récupérer des informations sur les classes avec la manipulation de std::string, il y a les classes internes, l'héritage multiple, les namespaces et pleins de trucs à gérer.

Il y a un truc bien par contre, je peux passer un pointeur sur l'application dans un .dll et appeler des fonctions donc l'utilisateur pourra créer une entité externe personnalisée et modifier les paramètres communs à toutes les entité dans ODFAEG Creator pour par exemple créer des animations et les ajoutés au personnage comme entités enfants.

Par contre pour modifier des paramètres personnalisé et créer des entités personnalisé il devra passé par une interface graphique, heureusement celle-ci va récupérer toutes les classes, et les fonctions automatiquement donc l'utilisateur n'aura plus qu'à rentré les valeurs.

-
Edité par OmbreNoire 18 décembre 2020 à 7:23:06

Salut! Je suis entraine de créer un nouveau composant de rendu, RaytracingRenderComponent! (Avec des compute shader)

C'est un peu lourd à faire car comme un compute shader ne dépend pas du pipeline, il faut envoyer tout les triangles et les sphères de lumière dans un buffer et utiliser les textures bindless pour faire un test sur tout les triangles d'un coup, il faut aussi calculer l'interpolation des couleurs et des coordonnées de textures soit même.

-
Edité par OmbreNoire 19 décembre 2020 à 17:32:17

J'ai dû laissé tombé le raytracing trop compliqué de déboguer ça avec un GPU ou tu ne peux pas afficher de texture en console, de plus, je n'arrive pas à faire ça de manière optimisée je pensais qu'avec les compute shader j'aurai un bon FPS mais non.