striiiiiiiiiiiiiiing - Page 44

int Task::manageTasks()
{
    printf("pwet");
    SDL_Event Events;

    while (true)
    {
    /* Check for event quit */
        SDL_PollEvent(&Events);
        if (Events.type == SDL_QUIT)
            return EXIT_SUCCESS;

    /* Run the current Module->manageEvents() */
        m_ModuleList.back()->manageEvents(&Events);

    /* Wait for synchro */

    /* Toggle draw/display buffers */
        SDL_Flip(Screen);
    }
}

void f(SDL_Event Events) {
 Events; // permet d'enlever le warning avec g++
}

void f(SDL_Event) // Un paramètre est bien attendu, mais pas de warning sur le fait qu'il est inutilisé
{
}

Zephyr (./1297) :
C'est tordu comme contournement, g++ propose une solution plus élégante :

void f(SDL_Event) // Un paramètre est bien attendu, mais pas de warning sur le fait qu'il est inutilisé
{
}

Folco (./1308) :
Je fais du polling, par défaut de ne savoir faire de l'évènementiel

Pour les abstractions au niveau des messages, il s'agit bien de faire des communications entre des objets qui s'ignorent, et à part inventer des fonctions friend dans tous les sens ou travailler avec tout en global, je ne vois pas trop comment faire autrement (à mon niveau).

Et pourquoi ne pas partager ces informations ? Une icone autant qu'une liste déroulante, une unité ou un ascensceur a besoin de savoir si la souris est là pour savoir quoi faire, non ? A moins qu'au niveau supérieur, on dise quoi faire faire à chaque élément affiché, ce qui contraint la classe supérieure à connaitre des données sur la classe inférieure, on revient toujours au problème de responsabilités et de délégation du travail.

J'ai fait le choix de la simplicité, mes essais pour tout abstraire ayant fini en une choucroute monumentale, sans une ligne de code "efficace" (faisant réellement avancer quelque chose dans le programme), par contre, yavait de la création d'objet et de l'allocation dans tous les sens. Au final, je n'ai rien fait (de concret).

Mais je suis preneur d'une esquisse de solution plus précise que "gestion souris + clavier" + "dessin" Une icone à qui je dit de s'afficher, elle a bien besoin de savoir comment est foutu le clavier pour le faire, à moins que je m'adresse 15 fois à cet objet en lui demandant différentes choses à chaque fois (et là, ça sera bien découpé mais bordelique).

Sinon, j'ai besoin d'une classe abstraite (Icon justement), de laquelle vont dériver toutes les icones de mon interface. Seulement, je crois que je ne peux pas avoir de données dans une classe abstraite, que des méthodes ? Et pourtant, les icones ont plein de choses en commun au niveau des données... Alors comment faire, une interface pour les méthodes et une classe pour les données, et un héritage multiple au final ? Ca me parait lourd...

GoldenCrystal (./1309) :
Perso je suis pas fan de l'événementiel pour les jeux, juste parce que tu peux « facilement » zapper un événement (genre key up) et que ça nique ton gameplay. (Je prends WoW comme exemple à ce titre)

keyState = readKeyState();
if (keyState & ~lastKeyState)
    sendMessageInt(EVT_KEY_DOWN, keyState & ~lastKeyState);
...
lastKeyState = keyState;

Brunni (./1313) :

GoldenCrystal (./1309) :
Perso je suis pas fan de l'événementiel pour les jeux, juste parce que tu peux « facilement » zapper un événement (genre key up) et que ça nique ton gameplay. (Je prends WoW comme exemple à ce titre)

Je ne vois pas de raison que ça arrive... si tu "oublies" un événement qui a été propagé c'est que tu as mal codé.

En fait il faut de toute façon une tâche qui s'occupe de "poller" et transforme cela en événements, genre:

keyState = readKeyState();
if (keyState & ~lastKeyState)
    sendMessageInt(EVT_KEY_DOWN, keyState & ~lastKeyState);
...
lastKeyState = keyState;

Et cette tâche peut être problématique si elle tourne dans un thread séparé. On est dépendant de la gestion du multitasking par l'OS, c'est à dire qu'il ne doit pas avoir de période sensible où ce thread est stoppé au profit de celui de la logique du jeu. Et typiquement Windows aime donner un boost à ce genre de threads, d'où... problème

Par contre ce n'est pas lié à l'événementiel en soi. Tu peux très bien faire un jeu sans événement mais qui sépare le rendu, l'input, la physique, le réseau, etc. dans des threads différents, et le même genre de problème peut arriver à ce moment-là.

GoldenCrystal (./1309) :
Bah justement, ils ne devraient peut être pas s'ignorer totalement. enfin, y'a au moins un truc qui devrait ne pas les ignorer.
Typiquement, un clic sur un bouton va appeler une méthode (on est d'accord jusque là non ? ), et c'est cette méthode qui va se charger de refléter le clic sur le reste du programme. (En lieu et place d'envoyer un message !)