Discussion :

[LapinGarou]

Bonsoir à tous.

Je développe mon moteur 3d en OpenGL, et actuellement, je cherche à faire mon propre GUI.
En ce moment, je suis entrain de compulser les sources de CEGUI, mais pour répondre à ceux qui me diront qu'il y a CEGUI, j'ai envie de faire le mien, histoire d'apprendre, et d'avoir un contrôle total.
J'aurai besoin de conseils, je ne sais pas par où commencer : faire un gestionnaire de messages à la windows, ou y a t-il une autre méthode ? Faut-il par exemple créer un thread pour gérer une barre de progression au chargement d'un niveau de jeu ? Comment gérer la réponse à un clic sur un bouton ? gestionnaire de messages, ou pointeur de fonction ?
(si vous voyez le genre de questions que je me pose... )

Merci.

[bafman]

c'est justement ce que j'ai eut à faire pour mon stage de fin d'étude .

en gros, tu a 3 groses parties dans un GUI :
- la gestion des evenements
- l'affichage
- la gestion du text (qui fait partie de l'affichage mais qui est tellement importantes que je la met dans une autre partie)

pour gérer tes evenements, tu a interet à créer un gestionnaire d'input qui va regrouper tout tes input (clavier, souris) et les re dispacher vers les bon controles. Ce qui est dure dans cette partie, c'est principalement de faire un système qui soit générique tout en permettant de prendre en compte les cas particulier du genre "j'ai cliqué sur la drop down, le menu est apparut, j'ai cliqué en dehors du menu sur un bouton, je doit donc rentrer le menu et envoyer l'evenement au bouton"... toute une partie de plaisir

pour l'affichage, c'est sans doute la partie la plus simple, une interface, c'est avant tout des quads décoré avec des bordures, affiché dans un ordre défini avec du clipping... bref, rien de bien compliqué quand on sait afficher des quads

Pour la partie affichage de texte, c'est beaucoup d'algo sur les chaine (gestion du retour à la ligne automatique par exemple). Ça demande de faire très attention à ça qu'on fait pour ne pas plomber les perfs.

ce que je te conseil, c'est, dans un premier temps de fair un système d'affichage hyper simple (juste des quads avec du texte simple dessus), pour développer le système d'input la dessus. Une fois que tu a un système d'input robuste, tu peut développer tout un ensemble de composants (on peut faire à peut près tous les composants possibles et imaginable avec seulement des label, des boutons et des zones d'input) et améliorer le système d'affichage.

un truc très important est de ne pas faire d'interface funky quand tu valide le système d'input. C'est assez difficile de valider l'entrée dans un composant quand il a une bordure, et autres eyes candy inutiles...

sinon, si tu veut un bon exemple d'archi d'API de GUI, regarde AWT et Swing de Java, il sont assez bien construit et facilement implementable

[Mat.M]

Bonsoir à tous.


J'aurai besoin de conseils, je ne sais pas par où commencer : faire un gestionnaire de messages à la windows, ou y a t-il une autre méthode ? Faut-il par exemple créer un thread pour gérer une barre de progression au chargement d'un niveau de jeu ? Comment gérer la réponse à un clic sur un bouton ? gestionnaire de messages, ou pointeur de fonction ?
(si vous voyez le genre de questions que je me pose... )

La réponse à un clic de souris c'est spécifique à l'OS..sous Windows il suffit de traiter le message WM_LBUTTONDOWN c'est de la programmation win32..
Tu peux t'inspirer des sources de SDL par exemple plus orienté multiplateforme et même mieux de Qt qui possède un système de gestion des événements par signaux assez intéressant..
Mais je conseille de faire quelque chose de simple au départ

[LapinGarou]

bafman> Merci, c'est un peu plus clair dans ma tête là.

Mat.M> Ok, ça détecte si le bouton est en haut ou en bas, mais ça ne me dit pas si ma fenêtre va être réduite, agrandie ou fermée dans mon GUI, ni même si on a 2x cliqué. Je pense que ça doit forcément être rattaché à mon gestionnaire pour ne serait-ce que compter le nombre clics et les intervalles, mais je vais devoir séparer cette partie de mon code du code win32, sinon ça ne me parait pas propre du tout de cette façon. (ou j'ai mal compris ce que tu as voulu dire)

[Happy]

Ma façon de voir la chose

Créer une structure pour chaque composant, à part: text, éditbox, bouton, scroll-bar, check etc.

Une fois tous crées et testés, on peux créer la structure GUI pour gérer tout ça, par exemple à base de planes.

Un plane peut être le bureau, une fenêtre, un tableau etc. mais, son point important c'est qu'il vas devoir gérer l'ordre d'affichage sur Z. Ainsi un plane pourra contenir tous les items de plus haut.

Quant à l'input, on peux le faire dans la structure GUI, puisqu'on aura la position du curseur, les états des boutons souris et clavier ( je pense à un truc portable ).

[Mat.M]

mais ça ne me dit pas si ma fenêtre va être réduite, )

Oui mais quel compil quel type de projet , win32 ? C++ ?
Il faut prendre la solution de Happy et faire ses propres classes de gestion de boutons de textes de messages et séparer les API spécifiques ( win32,XWindow ..) du reste du code
Pour le jeu que je développe je me suis fait mes propres classes CButton avec leurs propres méthodes de gestion de clic

[deadalnix]

Personnellement je te conseille de regarder comment est faite swing, lib graphique de java.

Ca peut te donner de tres bonnes piste pour faire un joli GUI.

L'important : bien separer modele vue et controleur. Tu creer des element (modele) que tu linke entre eux. Ensuite, tu creer un facon d'afficher ces elements.

Enfin, via des listener, tu gere les actions utilisateur sur ces elements.

Il est important de faire une pate de base solide en arriere plan, de laquelle tu va faire heriter tout les objets de ton GUI.

[Happy]

deadalnix, c'est une bonne chose la séparation modèle vue de contrôleur, je vais en prendre compte pour la prochaine Gui. Merci

[kremvax]

Je suis aussi en train d'écrire un GUI sous GL.
Déjà, utilises-tu GLUT? C'est pas mal pour s'affranchir de la gestion des inputs, spécifiques aux OS.

Perso j'ai structuré tout ça sur plusieurs niveau, avec un InputEngine qui interragit avec GLUT et qui détecte les double-clics, les drag & drop etc. , et un InputManager qui grosso-modo récupère les données de l'InputEngine et dispatche tout ça vers le module du jeu concerné (GUI, élément de jeu 3d, etc.)

Ensuite pour le GUI, je l'ai construit avec 3 classes de bases : guiFrame, guiWindow et guiComponent (chacune pouvant être dérivée à souhait) + un InterfaceManager qui gère l'ensemble des frames.

[edit]Comme l'a dit bafman, j'ai commencé par faire un affichage basique avec des QUADS colorés pour valider tout ça. Là je suis justement en train de passer aux textures.

Si ça t'intéresse d'en savoir plus demande-moi ce que tu veux et je peux aussi te filer le code source. (c'est en C++, avec GLUT donc)

[kremvax]

Par rapport à ta question : "Faut-il par exemple créer un thread pour gérer une barre de progression au chargement d'un niveau de jeu ?"
Perso j'ai pas encore découpé mon programme en multi-thread, mais si je le fais ce sera pour des choses un peu plus conséquentes histoire de tirer profit des architectures multi-core.

Pour faire une barre de progression, par exemple lors du chargement des textures d'un niveau, je me contenterais de ne pas charger toutes les textures d'un bloc, mais par exemple une seule par boucle de jeu en incrémentant un compteur pour que la barre de chargement se mette à jour lors de son update. De toutes façons le chargement en mémoire vidéo d'une texture est probablement plus long que la durée d'une boucle où l'on affiche trois fois rien, donc ce n'est pas une perte de temps de ne charger qu'une texture par frame.