Discussion :

[Franck.H]

Bonjour,

Je vais essayer de vous faire voir ce qu'il faut parce que c'est sur mon moteur de mon futur jeu donc c'est du gros dossier

Bon, en premier lieu, il s'agit d'une intégration d'une petite API pour créer et gérer des widgets en SDL pour mon moteur, jusque là rien de bien compliqué, la suite ....

Dans le fichier bdialog.c à partir de la ligne 164, je gère la possibilité d'un événement utilisateur pour mon widget destiné à créer des boîtes de dialogues, tu verras ma solution temporaire à la ligne 181

Ensuite, je travail essentiellement avec des pointeurs, tu peux le remarquer à la ligne 148 su même fichier. Voici les détails de la fonction bengine_get_event dans le fichier bengine.c à partir de la ligne 100. La structure privée contenant le SDL_Event se situe en haut du fichier, ligne 57 !

Voilà, c'est à peu près tout ce qu'il faut savoir, il n'y a pas un grand cheminement des données, j'ai essayé de rester le plus simple et pratique possible par rapport à l'envergure de mon projet. Tu peux voir mon main de test du moteur dans mon fichier main.c

Le test que j'avais effectué était une fonction utilisateur (un callback) sur l'événement mouse_motion de ma boîte de dialogue. Le but de cette fonction qui n'existe plus dans le main, était d'afficher les coordonnées de la boîte. Ca fonctionnais bien mais même lorsque j'arrêtais de faire bouger la souris, j'affichais toujours la dernière position de la fenêtre, ce qui est un peu gênant


J'espère que ca vous ira comme pistes parce que ca deviens de plus en plus gros alors pour montrer un problème et si tout est dispatché en modules ... ca pas très pratique

[fearyourself]

Ok je viens de regarder ton code, j'avoue que cela me rend en fait bien perplexe.

Je vois plusieurs problèmes à comment tu as dispatché ton système de gestion d'événements.

Tu as voulu mettre un événement central pour pouvoir gérer l'événement pour chaque élément (passant donc un élément dans une structure qu'on récupère avec bengine_get_event)

1) Pourquoi ne pas déclarer p_bengine static vu que tu passes par des fonctions ensuite ?

Dans ta gestion des événements, tu mets effectivement une jolie boucle while :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
            while (SDL_PollEvent (p_event))
            {
               switch (p_event->type)
               {
                  case SDL_QUIT:
                  {
                     b_quit = SDL_TRUE;
                  }
                  break;
 
                  case SDL_KEYDOWN:
                  {
                     if (p_event->key.keysym.sym == SDLK_ESCAPE)
                     {
                        b_quit = SDL_TRUE;
                     }
                  }
                  break;
               }
            }

2) Mais si c'est un clic de souris ou un mouvement d'un joystick, tu ne le gères pas. Tu espères que tu n'auras pas d'autres événements qui vont écraser les valeurs dans ta variable p_event.

Parce que s'il y a un événement clavier qui passe après ton clic souris, BAM tu te fais avoir.

En effet, vu que tu ne gères pas les événements en directement quand tu les recois, tu es obligé de remettre la valeur du type à une valeur non utilisée puisque sinon au prochain rendu, le widget va regarder de nouveau cette valeur.

Une solution serait que le widget concerné consumme l'événement en modifiant le type de l'événement.

Malheureusement pour les raisons que j'ai cité plus haut, je ne vois pas comment cette architecture est en fait viable. Dès que tu auras plusieurs événements en même temps tu ne pourras pas garantir que les événements soient correctement gérés.

Jc

[Franck.H]

1) Pourquoi ne pas déclarer p_bengine static vu que tu passes par des fonctions ensuite ?

En effet, j'avais pas remarqué mais normalement le compilateur le fait implicitement si c'est dans un fichier source non ?

2) Mais si c'est un clic de souris ou un mouvement d'un joystick, tu ne le gères pas. Tu espères que tu n'auras pas d'autres événements qui vont écraser les valeurs dans ta variable p_event.

...

En effet, vu que tu ne gères pas les événements en directement quand tu les recois, tu es obligé de remettre la valeur du type à une valeur non utilisée puisque sinon au prochain rendu, le widget va regarder de nouveau cette valeur.

Oui en effet mais SDL_Event ne contient à chaque que un seul événement à un instant donné non ? Ou bien s'agit-il d'une pile ? Car à mon sens et comme j'ai fait, si un événement utilisateur surviens, tous les widgets étant automatiquement parcourus à un instant donné, l'événement sera automatiquement capté par le widget visé et dans le pire des cas, si c'est un événement non géré bin rien ne se passe tout simplement.

Malheureusement pour les raisons que j'ai cité plus haut, je ne vois pas comment cette architecture est en fait viable. Dès que tu auras plusieurs événements en même temps tu ne pourras pas garantir que les événements soient correctement gérés.

Je suis ouvert à toutes propositions d'amélioration de ma gestion des événements, le moteur lui même n'est pas fini alors c'est encore le bon moment pour faire des changements/optimisations


Merci

[fearyourself]

Oui en effet mais SDL_Event ne contient à chaque que un seul événement à un instant donné non ? Ou bien s'agit-il d'une pile ?

En effet, c'est un seul événement et pas une pile.

Car à mon sens et comme j'ai fait, si un événement utilisateur surviens, tous les widgets étant automatiquement parcourus à un instant donné, l'événement sera automatiquement capté par le widget visé et dans le pire des cas, si c'est un événement non géré bin rien ne se passe tout simplement.

Justement ! Tu ne parcours pas tous tes widgets pour chaque événement mais seulement quand tu sors de ta boucle événementielle.

C'est là le problème !

Je suis ouvert à toutes propositions d'amélioration de ma gestion des événements, le moteur lui même n'est pas fini alors c'est encore le bon moment pour faire des changements/optimisations

La seule solution : parcourir tous les objets susceptibles d'être intéressé par un événement à chaque itération de la boucle.

La solution que j'avais choisi : utiliser une solution de focus, du coup seul l'objet actif recoit les événements et seulement pendant un clic doit on faire un parcours. Et encore, la liste des objets sont triés par profondeur du coup, dès qu'on trouve un objet dans la ligne de mir du curseur, on s'arrête.

Jc

[Franck.H]

Oui en effet, je parcours tous les widgets présents et ce par le moyen de la boucle qui affiche les widgets car c'est une fonction conjointement lié à celle des événements.

Ce que je peut éventuellement faire, si j'ai bien compris ton résonnement et que je soit pas obligé de modifier la moitié de mon code, est de faire un parcours séparé des widgets par rapport à celui qui posède le focus (un petit flag à ajouter pour son adresse, rien de bien complqué).

Ca fairais donc en somme, une gestion bien séparée pour les événements des widgets ce qui est en effet pas plus mal.

Voulant faire le plus simple possible j'avais fait un parcours global par rapport aux fonctions d'affichage de chaque widget mais j'avais pas pensé à ce problème.


Ca me fera du boulot pour la semaine prochaine quand je me remettrait sur mon beau projet


Si tu as d'autres remarques à faire hésite pas, merci

[fearyourself]

Oui en effet, je parcours tous les widgets présents et ce par le moyen de la boucle qui affiche les widgets car c'est une fonction conjointement lié à celle des événements.

C'est aussi ce que j'ai vu

Ce que je peut éventuellement faire, si j'ai bien compris ton résonnement et que je soit pas obligé de modifier la moitié de mon code, est de faire un parcours séparé des widgets par rapport à celui qui posède le focus (un petit flag à ajouter pour son adresse, rien de bien complqué).

Voilà, moi en fait je passais l'événement au Moteur de jeu (ton bengine) et il décidait ce qu'il en faisait. Evénement clavier passait d'abord par l'élément en focus et si cela lui intéressait il le prenait sinon le moteur le gérer.

Ceci était facilement possible en utilisant ce genre de code pour la gestion du clavier :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
void promain_keyb(unsigned char touche, int x, int y)
{
    if(!windowhandler.key(touche,x,y))
    {
    switch(touche)
      {
            case 'q':
                promain.save("maingame");
                exit(1);
                break;
      }         
    }           
}

Donc lorsque le moteur recoit un événement clavier, il l'envoit au gestionnaire de fenêtres qui fonctionne comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
//Returns if we captured the key or not
bool ComponentHandler::key(unsigned char k, int x, int y)
{
    //Send the key event to the last selected component
    if(last_select)
        return last_select->call_key(k,x,y);
    else
        return false;//false means we didn't use the key
}

Donc pour la lettre 'q' par exemple, soit le widget (pour toi ) l'utilise et du coup on ne veut pas sortir du programme, soit le programme s'en sert et donc on sort...

Ca ferais donc en somme, une gestion bien séparée pour les événements des widgets ce qui est en effet pas plus mal.

Voulant faire le plus simple possible j'avais fait un parcours global par rapport aux fonctions d'affichage de chaque widget mais j'avais pas pensé à ce problème.


Ca me fera du boulot pour la semaine prochaine quand je me remettrait sur mon beau projet

Il vaut toujours mieux séparer l'affichage du reste. Cela permet de faire un code plus propre et plus sympa lorsque tu veux gérer certains détails (mettre un pause en place par exemple).

Si tu as d'autres remarques à faire hésite pas, merci

Il faudrait que je regarde un peu plus ton code , avec tes informations, j'avais tout de suite capté le problème !

Jc

[Franck.H]

Bon, ca va tout de même me faire pas mal de boulot ... chez moi tout est lié, tu peux le voir dans la boucle principale qui appele mon module de gestion de rendu des objets.

Si une fonction par exemple d'affichage d'une boîte de dialogue est dans la file de traitement du module bdrawshed (Bengine Draw Sheduler), et bien ca lance une réaction en chaîne, cette réaction c'est la fonction de rendu de la boîte de dialogue qui gère elle-même l'appel des fonctions de rendu de ses widgets enfants.

Pour finir, au début de chaque fonctions de rendu des widgets se trouve l'appel de leur fonction respective de traitement des événements utilisateur.

Voici en gros comment se déroule le processus, je pensais bien faire

[fearyourself]

Bon, ca va tout de même me faire pas mal de boulot ... chez moi tout est lié, tu peux le voir dans la boucle principale qui appele mon module de gestion de rendu des objets.

Si une fonction par exemple d'affichage d'une boîte de dialogue est dans la file de traitement du module bdrawshed (Bengine Draw Sheduler), et bien ca lance une réaction en chaîne, cette réaction c'est la fonction de rendu de la boîte de dialogue qui gère elle-même l'appel des fonctions de rendu de ses widgets enfants.

Pour finir, au début de chaque fonctions de rendu des widgets se trouve l'appel de leur fonction respective de traitement des événements utilisateur.

Voici en gros comment se déroule le processus, je pensais bien faire

Oui et cela ne change pas grand chose. Il faut sortir cette gestion d'événements que tu as imbriqué dans le code de rendu. Ensuite, la gestion des événements se fera de la même facon.

Si ta boîte de dialog contient des widgets, alors elle aura aussi une boucle pour les widgets qu'elle contient.

Tu auras donc le même genre de propagation d'information que tu avais pour l'affichage.

Jc

[Franck.H]

Ouais en gros je fait un gestionnaire d'événement bien séparé du reste et chaque widget sera traité bien à part et non en profondeur par rapport à un autre widget comme j'ai fait..

[Franck.H]

Bon, après quelques modifications pour séparer la gestion des événements bin ... ca marche un peu moins bien qu'avant j'dois dire. Je ne sais pas si c'est lié mais les événements de tous les widgets sont tous traités avant l'affichage donc j'ai des latences et des événements comme le clique sur un bouton de commande ne marche pas toujours au top...

Je fait ainsi désormais:

Code :

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

1
2
3
4
5
6
7
8
void bengine_main (void)
{
   if (p_bengine != NULL)
   {
      gui_events ();
      bdrawshed_loop ();
   }
}

Cette fonction est donc appelée depuis la boucle principale qui se trouve dans le main. Donc en résumé, je parcours les widgets présents (pour le moment juste un BButton) pour les événement puis se fait ensuite l'appel pour l'affichage.

Je ne vois pas comment faire mieux étant donné que la gestion des événements et la gestion du rendu sont maintenant bien séparées !

Aurait-tu des suggestions ou pistes à suivre ?

Faut juste dire qu'avant, je traitais les événements de chaque widgets juste avant le propre affichage et ca, un par un et non comme maintenant où je m'occupe d'abord des événements et seulement ensuite de l'affichage !

[fearyourself]

Ok désolé du retard dans la réponse, j'ai été débordé... Je viens de télécharger tes dernières sources.

Je ne suis toujours pas d'accord sur certains points :

- Maintenant tu appelles l'affichage vraiment trop souvent (à chaque événement!)

- Je pense que quelque chose comme ceci serait mieux :

Code :

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

1
2
3
4
5
6
7
void bengine_main (void) 
{  
  if (p_bengine != NULL)  
    {  
    bdrawshed_loop (); 
     } 
}

Et je ferais ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
         while (! b_quit)
         {
            SDL_Event * p_event = bengine_get_event ();
 
 
            while (SDL_PollEvent (p_event))
            {
               switch (p_event->type)
               {
                  case SDL_QUIT:
                  {
                     b_quit = SDL_TRUE;
                  }
                  break;
 
                  case SDL_KEYDOWN:
                  {
                     if (p_event->key.keysym.sym == SDLK_ESCAPE)
                     {
                        b_quit = SDL_TRUE;
                     }
                  }
                  break;
                 case SDL_MOUSEBUTTONUP:
                 case SDL_MOUSEBUTTONDOWN:
                 case SDL_MOUSEMOTION:
                          gui_events ();
                 break;
                }
            }
               /*
                * Entree du moteur.
                */
               bengine_main ();
         }

Ensuite il faudrait que je regarde de plus près pour bien comprendre le cheminement que feront les différents appels...

Jc

[Franck.H]

Mouais... tu sais, ca change rien du tout. D'ailleurs, je ne l'appel pas plus souvent qu'avant, même dans ma première version mais ce qui me choque c'est la lenteur de réaction aux événements, me dit que ma première solution reste encore la meilleure à l'heure actuelle car là au moins ca fonctionne instantanément

Je ne saurais dire pourquoi mais les faits sont là, et là les tests portent seulement sur une boîte de dialogue et un bouton de commande, on ne peut pas dire que c'est beaucoup de choses

J'ai beau remuer dans tous les sens, ca accroche et je ne vois pas pourquoi

Le cheminement en lui même n'est pas des plus compliqué, dans la boucle des événements je traite les widgets qui sont dans la liste. Idem pour la fonction d'affichage, elle parcours la liste de rendu et dans ce cas précis, fait un appel à la fonction d'affichage du widget courant, ni plus ni moins. Je ne peut pas faire plus court chemin que celui-ci !


Voilà, si tu arrives à trouver le pourquoi du comment je suis tout ouï mais là franchement je vois pas

[fearyourself]

Je vais tenter de voir ce qui peut bien clocher mais le problème c'est que ton code ne semble pas compilable sous Linux (du moins il semblerait manquer un makefile)

Jc

[Franck.H]

Je vais tenter de voir ce qui peut bien clocher mais le problème c'est que ton code ne semble pas compilable sous Linux (du moins il semblerait manquer un makefile)

Jc

Le code est créé sous Linux même C'est un projet Code::Blocks tout simplement (un projet Linux et même un projet Win )

[fearyourself]

Le code est créé sous Linux même C'est un projet Code::Blocks tout simplement (un projet Linux et même un projet Win )

Ok, alors je réinstalle CodeBlocks et en avant pour voir ton code en action

Jc

PS: Trop fort, faut que je lise mon propre tutoriel sur comment on doit faire

[Franck.H]

PS: Trop fort, faut que je lise mon propre tutoriel sur comment on doit faire

[Franck.H]

Tiens tiens, je viens de tester un truc, je suis passé sur le gestionnaire de fenêtre Metacity (de Gnome) au lieu de Beryl (en fait la MàJ de Beryl à entrainé un bug dans l'utilisation de XGL et AIXGL chez moi ca rame) pis g relancé le test de mon moteur pis là surprise, c'est presque parfait dans l'intervale entre la gestion des événements et l'affichage

Bon c'est pas encore le top du top mais là au moins je peut bien tester maintenant

Bizzare que le gestionnaire de fenêtre à si grande influence sur le reste des programmes, bon c'est sûr, ce n'est qu'une version beta donc bon, faut pas trop en demander non plus

[fearyourself]

Tiens tiens, je viens de tester un truc, je suis passé sur le gestionnaire de fenêtre Metacity (de Gnome) au lieu de Beryl (en fait la MàJ de Beryl à entrainé un bug dans l'utilisation de XGL et AIXGL chez moi ca rame) pis g relancé le test de mon moteur pis là surprise, c'est presque parfait dans l'intervale entre la gestion des événements et l'affichage

Bon c'est pas encore le top du top mais là au moins je peut bien tester maintenant

Bizzare que le gestionnaire de fenêtre à si grande influence sur le reste des programmes, bon c'est sûr, ce n'est qu'une version beta donc bon, faut pas trop en demander non plus

Je pense que c'est une question de charge, avec Beryl tu as moins de ressources. Alors, j'ai regardé un peu ton code et je ne suis pas d'accord sur quelques détails :

- Tu parcours toujours TOUS les widgets pour un événement, même s'il ne les regarde pas.
- Tu n'arrête pas le parcours de gestion d'événement si un widget a déjà capturé l'événement.

Pour le deuxième point :
- Sauf si je me trompe, je ne vois pas un événement qui pourrait servir pour deux widgets en même temps.
- Si c'est le cas alors tu as raison.

Pour le premier point, il faut implémenter une vérification de proximité. Je veux dire que si la souris n'est pas dans la boîte de dialogue alors le bouton contenu dedans ne peux pas recevoir de clic.

Ceci se fait de la même facon que tu as géré l'affichage, en passant par le parent. Si le clic contient le parent, alors tu vérifies les enfants.

Ensuite, si un des enfants a utilisé l'événement, tu arrêtes.

Enfin, en sortant l'affichage de la boucle, ton code tourne bien sur mon ordi mais je pense que s'il y a 50 widgets, ca risque de commencer a ramer si tu ne change pas ta facon de faire le parcours.

Jc

[Franck.H]

Je pense que c'est une question de charge, avec Beryl tu as moins de ressources. Alors, j'ai regardé un peu ton code et je ne suis pas d'accord sur quelques détails :

- Tu parcours toujours TOUS les widgets pour un événement, même s'il ne les regarde pas.
- Tu n'arrête pas le parcours de gestion d'événement si un widget a déjà capturé l'événement.

Oui je sais, je suis en train de faire quelques modifs justement pour gérer ca en mieux et arrêter le parcours des événements si un widget a déjà capturé l'événement courant.

Par ailleurs, j'ai mis en place un système de focus ce matin.

Pour le deuxième point :
- Sauf si je me trompe, je ne vois pas un événement qui pourrait servir pour deux widgets en même temps.
- Si c'est le cas alors tu as raison.

Heu non, rien de tel.

Pour le premier point, il faut implémenter une vérification de proximité. Je veux dire que si la souris n'est pas dans la boîte de dialogue alors le bouton contenu dedans ne peux pas recevoir de clic.

Ceci se fait de la même facon que tu as géré l'affichage, en passant par le parent. Si le clic contient le parent, alors tu vérifies les enfants.

Heu de toutes manière lorsque je click sur un widget c'est que forcément la souris se trouve au moins dans l'espace d'une boîte de dialogue.

Ensuite, si un des enfants a utilisé l'événement, tu arrêtes.

En cours ...

Enfin, en sortant l'affichage de la boucle, ton code tourne bien sur mon ordi mais je pense que s'il y a 50 widgets, ca risque de commencer a ramer si tu ne change pas ta facon de faire le parcours.

Jc

Je ne vois pas bien ce que ca change que ce soit ou non dans la fonction bendine_main car de toute manière chacune des deux fonctions seront appelées et dans le même ordre ainsi que dans le même intervale de temps (plus ou moins).

Une fois que j'aurais fini tout ce que j'ai commencé, il n'y aura même plus de réaffichage sans qu'il ai d'action de la part de l'utilisateur, je pense que cela reste une meilleure solution du point de vue des performances !

[fearyourself]

Oui je sais, je suis en train de faire quelques modifs justement pour gérer ca en mieux et arrêter le parcours des événements si un widget a déjà capturé l'événement courant.

Par ailleurs, j'ai mis en place un système de focus ce matin.

Ah bien ca

Heu de toutes manière lorsque je click sur un widget c'est que forcément la souris se trouve au moins dans l'espace d'une boîte de dialogue.

Oui mais c'est un peu comme la raison d'avoir un octree en fait. Si tu as une fenêtre qui a 30 widgets mais que la souris n'est même pas dans la fenêtre, pourquoi parcourir ses widgets ?

En testant si la souris est dans la boîte de dialogue tu évites des tests lorsque la souris ne l'est pas.

Je ne vois pas bien ce que ca change que ce soit ou non dans la fonction bendine_main car de toute manière chacune des deux fonctions seront appelées et dans le même ordre ainsi que dans le même intervale de temps (plus ou moins).

Ah non, si tu as 20 événements en attente, tu affiches et parcours les widgets 20 fois.

Par contre, en sortant l'appel de l'affichage tu appelles la gestion gui_events 20 fois (normal) mais l'affichage une seule fois (logique on prend tous les événements en compte et après on réactualise)

Une fois que j'aurais fini tout ce que j'ai commencé, il n'y aura même plus de réaffichage sans qu'il ai d'action de la part de l'utilisateur, je pense que cela reste une meilleure solution du point de vue des performances !

C'est vrai, mais quand tu vas mettre le jeu en place, il y aura toujours un réaffichage en place pour les animations par exemple donc est-ce vraiment utile ?

Jc