Discussion :

[maeiky]

Pour les copies, ces classes ne sont pas lourde à copier, j'en avais déjà discuté une fois avec l'auteur de la SFML de passer cela par référence plutôt que par copie et il m'a répondu que ce n'était pas grave car ces classes ne sont pas lourde à copier.

Ce qui bouffe le plus d'après mais tests c'est l'api en elle même, donc c'est juste l'api qui doit être gourmande mais aussi mon PC qui doit se faire vieux.

Ha oui et il y a aussi le fait que mon CPU consomme 100% tandit que mon GPU seulement 30%.

Si c'est l'auteur de la SFML alors ça change tout . Tu fais n'importe quoi sans en comprendre les impactes, tu ne comprend même pas ce qui est la base de la base, ça va jusqu'au simple casting d'entier signé/non signé, je n'ai jamais vue pire programmeur.

Mais ça, c'est parce que je suis dépendant de l'api openGL qui apparemment n'utilise pas le GPU à 100%, donc ça je ne peux rien y changer.

Une cause désespéré

[Invité]

Amélioration de la mise en forme du site web pour la partie documentation de ODFAEG!

Je n'ai plus qu'à mettre un lien sur chaque page qui enverra vers le chapitre suivant.

La semaine prochaine je continue ODFEAG creator!

[foetus]

Pour l'installation je me suis rendu compte que je pourrai réduire le temps, car, il y a des moments dans la vidéo ou j'étais un peu perdu..., ou j'ai cliqué sur un mauvais lien, etc...

Je te rassure: 42 vidéos de tutoriels pour faire un pong en réseau (je dirais au pif 42 * 15 minutes), il faut être un WARRIOR pour regarder et comprendre


Et je ne suis pas expert, mais ton pong (2 traits et un rond ) (vidéo 41 ou vidéo 42) n'est même pas fluide: on devrait voir la trace de la balle. En plus que la balle se traîne.

Et lorsque je vois ce bout de code ou ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

    Vec2f m = static_cast<BoundingBox*>(entity->getCollisionVolume())->getEdgeNormals()[info.nearestEdgeIndex1];

2 déférencements et 1 index non testés

[Neckara]

Pour ta vidéo, tu peux utiliser avidemux sous Linux pour couper certaines parties plutôt que de conserver la vidéo originale.

[Invité]

Au fur et à mesure que ODFEAG creator avance, le design du framework aussi.

Pour chaque composants on peut désormais choisir la fenêtre sur laquelle on souhaite rendre le composant.

La méthode onUpdate désormais renvoie un pointeur sur la fenêtre (les événements ne sont renvoyé que pour les fenêtres qui ont le focus)

Comme pour les composants il faut ajouter la fenêtre à l'application.

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
winTerrainGen = new RenderWindow(sf::VideoMode(500, 300), "Terrain parameters", sf::Style::Close, getRenderWindow().getSettings());  
addWindow(winTerrainGen);

Lors du traitement des événements onUpdate renvoie un pointeur sur la fenêtre active. (Celle qui a le focus)

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
void ODFAEGCreator::onUpdate(RenderWindow* window, sf::Event& event) {
    getListener().setCommandSlotParams("MoveAction", this, event.key.code);
    if (&getRenderWindow() == window && event.type == sf::Event::Closed) {
        //Si on ferme la fenêtre principale, on sort de l'appliction ODFAEG.
        stop();
    } else if (window == winTerrainGen && event.type == sf::Event::Closed) {
        //Sinon, on ferme la sous fenêtre sans quitter l'appliction. :)
        winTerrainGen->close();
    }
}

Je vais enchaîner sur les autres types de GUI dont j'ai besoin.

Je ne compte pas implémenter des layout mais je vais faire pour chaque fenêtre un "content pane" qui sera un composant parent pour toute les fenêtres.

On pourra alors, se servir de la position et de la taille des composants parent pour ajuster la taille des composants enfants, à l'aide d'une simple méthode :

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
composantEnfant->setRelativeToParent(0, 0, 50 , 50);

Dans ce cas là le composant enfant occupera la moitié de la taille du composant parent. (50% de la taille en x et en y)
Les deux premiers indiqueront le % de décalage par rapport au bord (au coin haut gauche) du composant.)
Ceci est plus simple que les layouts, il n'y aura donc pas de layout pour odfaeg comme c'est le cas pour Qt et pour la librairie AWT de l'api java.
Comme vous pouvez le voir ici je suis entrain de faire la fenêtre pour la paramétrer la génération de terrains.

[foetus]

Dans ce cas là le composant enfant occupera la moitié de la taille du composant parent. (50% de la taille en x et en y)

Bof je trouve le système très restrictif:

1) Pourquoi vouloir que le panel n'ait pas une taille fixe? ou comme Qt qu'il ait une taille minimale et une maximale? ou comme Android/ Responsive Design: adapter sa taille en fonction de la taille fenêtre parente?

2) Avec des pourcentages, on est plus en "pixel perfect" et donc il manque une notion de strut, spring, ressort, entretoise, "je-ne-sais-pas-comment-le-nommer"

Un exemple: Tu mets 2 panels empilés de haut en bas, mais avec un espace entre. Si ton espace est petit (disons 10 pixels pour l'exemple), le panel du dessus peut venir recouvrir le panel du dessous si la taille de ton parent est grand.
Ou alors prévoir une méthode callback/ block - fonction anonyme/ autre ... AfterResizeBeforeUpdate et c'est l'utilisateur de ta bibliothèque à faire du code +/ - inutile

[Invité]

J'ai allégé le framework en retirant tout les composants ne fonctionnant pas, j'ai enlevé le support de l'opengl moderne car ça ne fonctionne pas également avec mon driver.

J'ai également retiré tout les std::thread, et les std::mutex, car ça complique le code, ça ne fonctionne pas avec X11 et en plus, ça n'optimise pas.

En résumé j'ai donc retiré toutes les optimisations prématurées que j'avais faîte.

Par contre, j'ai rajouté des guis, car, c'est la seule chose qu'il manque encore à mon framework à vrai dire pour faire ODFAEGCREATOR.

Les nouveaux composants guis sont filedialog pour séléctionner des fichier à charger, panel pour ajouter plusieurs composants guis dessus et les placer avec la layout que j'ai cité ci-dessus, et bien sûr les labels.

Il ne manquera plus que les cases à cocher donc, les combos box, ainsi que les tableaux. (Mais je n'ajouterai que ceux dont j'aurai vraiment besoin dans ODFAEG creator, les tableaux, je ne pense pas en avoir besoin)

Ne vous en faîte pas, il est impossible que les composants se superposent à partir du moment ou vous réfléchissez bien aux % que vous mettez, et on peut encore faire du pixel perfect pour avoir une taille fixe, il suffit d'utiliser les méthodes setPosition et setSize plutôt que setRelToParentLayout.

[maeiky]

Et pense à passer tes classes en paramètre par références et non par copie, la correction est simple (ajouter &). Aussi ça serait bien d'utiliser des shared_ptr pour éviter au maximum les copies inutiles.

[Invité]

Salut, les dons me servirons à acheter du nouveau matériel pour VULKAN.

[skeud]

Salut, les dons me servirons à acheter du nouveau matériel pour VULKAN.

[HumourNoir]tu auras plus de chance de gagner de l'argent en faisant la manche qu'un appel au don[HumourNoir]

Question plus sérieuse, pourquoi irait-on te donner de l'argent?

[maeiky]

[Bousk]

En 1 mois le projet a été arrêté, mis en pause, repris, déclaré terminé, réouvert, en version finale, prêt pour faire des projets de jeu, le tout en crachant sur OpenGL, puis sur Vulkan, puis sur OpenCL, puis en déclarant qu'aucun d'eux n'était assez puissant pour ton truc, puis revenu en arrière, puis en attente de Vulkan.
Et maintenant tu fais une "campagne de dons" pour qu'on te sponsorise ta prochaine machine ???

[Invité]

Salut.

Je met en pause le projet ODFAEG Creator, car, au niveau de la mémoire, je suis arrivé à saturation! (J'ai des conflits de données en mémoire (trop de données) sur les serveurs)

En comptant tout vos messages inutiles en plus qui n'aide pas, cela commence à faire beaucoup.

Je vais donc chercher tout mes posts et les supprimer, je reprendrai le projet lorsque ses soucis de conflits mémoire seront réglés.

[maeiky]

Mais de quel serveur parle tu ... et puis quel est le rapport avec ODFAEG Creator

[zecreator]

Bonjour,

C'est un projet très intéressant. Mais il a l'air très orienté jeux "Desktop".
Suis-je le seul à croire en l'avenir du jeu HTML5 ?

Zecreator.

[maeiky]

Je dirais plus Html5/WebGL1 & 2. Mais ce qui rend intéressant un moteur de nos jour, c’est quand il est un maximum portable sur différentes plateformes.

[Invité]

Salut, le moteur ne sera malheureusement pas portable, il ne fonctionnera que sur ma machine comme pour toutes mes applications d'ailleurs, car, certains en ont trop profité pour faire du profit derrière mon dos.

Je ne peux donc plus me permettre de faire la même erreur car le jour ou je me retrouverai à nouveau dans cette galère ce n'est pas ces gens là qui vont faire le travail à ma place, ni, me secourir financièrement.

Bref, heureusement qu'il y a la sécurité sociale.

Bref en ce qui concerne ODFAEG Creator celui-ci avance bien car j'ai déjà pu compiler et exécuter une simple application au moyen de l'interface graphique!

Le plus difficile restera à se positionner dans la zone de texte au bonne endroit lors des clics de souris à l'édition des scripts c++.

Bref, l'avantage c'est qu'au niveau du linkage il n'y a plus rien à paramétrer, la seule chose qu'il suffira de faire c'est d'installer les dépendances mais sous linux c'est facile à faire.

Mais c'est beaucoup de boulot, donc, je ne sais pas exactement quand j'aurai fini cet outil.

[CodeurPlusPlus]

Salut, le moteur ne sera malheureusement pas portable, il ne fonctionnera que sur ma machine (...)

Heeeeeeiiiiiiinnnnnn ?

[zecreator]

Pareil que CodeurPlusPlus : Heeeeeeiiiiiiinnnnnn ?

Le C/C++ c'est bien, mais aujourd'hui, développer un moteur de jeu en ignorant le support web, c'est risqué. Il faut voir le nombre de jeux qui sortent chaque jour et qui sont développés en WEBGL. Sans compter le nombre grandissant d'appli mobiles développés en HTML5 et encapsulées dans une webview. Les moteurs javascript sont étonnement performants. Prenez THREEJS pour la 3D ou encore PIXIJS.

Un outil comme GDevelop, qui est gratuit, permet de faire des jeux très rapidement, aussi bien pour le support Desktop (C/C++) que pour le web.
Zecreator

[nikau6]

Si j'ai bien compris, tu fais un appel aux dons pour un moteur de jeux qui ne fonctionnera que sur ta machine ? Ça n'est pas très logique. Les programmeurs ne sont-ils pas sensés être des individus logiques ? Mets ton raisonnement dans une boucle et tu verras qu'il ne va pas fonctionner.