striiiiiiiiiiiiiiing - Page 49

Ah bon ça va, c'est juste que je chargeais un module qui n'existe pas encore, donc qui n'initialisais pas ses pointeurs de fonctions. Maintenant ça marche, mes boutons s'affichent et sont cliquables, le curseur de souris est géré, plus qu'à faire les sprites suivant le module d'intro. j'ai mis 3 jours à faire en C "objet" ce que j'ai pas fait en 3 semaines de C++. Courage, un jour petit Folco deviendra grand

Et encore un truc où je coince, un !

    if (mouse.buttons & SDL_BUTTON_LEFT)
    {
        for (i = 0; i < data->numIcons; i ++)
        {
            if ((mouse.x >= data->iconList[i].position.x) &&
                (mouse.y >= data->iconList[i].position.y) &&
                (mouse.x <= (data->iconList[i].position.x + data->iconList[i].position.w - 1)) &&
                (mouse.y <= (data->iconList[i].position.y + data->iconList[i].position.h - 1)))
                data->iconList[i].execOnClick((struct MODULE_DATA*) data);
        }
    }

Ca, ça marche nickel ! (on notera la manière de lire si le clic gauche est enfoncé)

Par contre :
while (SDL_GetMouseState(NULL, NULL) & SDL_BUTTON_LEFT);
(avec mouse.buttons == SDL_GetMouseState(NULL, NULL))

je m'attendais à ce que ça me fasse un idle tant que le clic gauche est enfoncé. Alors ça idle, mais ça s'arrête jamais, même quand je relache, ya une faute de logique qui vous saute aux yeux ?

(Et sinon ayé ça marche, mes chargement/déchargements/empilements de modules marchent, les icones avec leurs fonction d'exécution marchent et tout et tout Ca me prend 10 minutes de recoder un nouvel écran, du coup toute la partie présentation/chargement du jeu avance maintenant à la vitesse grand V \o/)

hmmm... ça serait pas une histoire de volatilité et de fonction sortie du while des fois ?

D'après la documentation de SDL, ça semble être basé sur de l'événementiel, en se faisant passer pour du non événementiel (c'est très con je trouve mais bon)…
Bref, l'« état actuel » est constant puisque c'est l'« état actuel » de la dernière fois ou tu as eu vent du vrai état actuel…

Quelle connerie...
J'ai essyé ça (entre autres) :

            while (1)
            {
                if(SDL_GetMouseState(NULL, NULL)&SDL_BUTTON_LEFT)
                    printf("Mouse Button 1(left) is pressed.\n");
                else
                    break;
            }

Résultat, après 1 clic, "Mouse button 1 is pressed" défile indéfiniment en console, même si le clic est releasé (et donc on quitte pas le while évidemment...)

Je vais essayer avec une variable can_click mise à 1 quand le clic est releasé... génial, il n'y a pas de FlushEvent ou WaitNoEvent

Bon alors, de toutes façons, c'est pas la bonne manière de faire. (Détail: ça va bloquer tout ton programme, alors que tu veux plus que probablement répondre à d'autres événements et rafraichir l'écran)
Ensuite, si c'était vraiment ce que tu veux faire (mais je t'ais dit que c'est mal !), la fonction que tu recherches est SDL_PumpEvents d'après la doc. (C'est pas marqué clairement mais les exemples de code disent que c'est ça)
Ensuite, la bonne manière de détecter un clic / appui de touche (ou l'inverse) avec du non événementiel, c'est un truc comme ça: bool key_state; // Défini quelque part // […] void machin_truc_chose() { bool new_key_state = get_key_state(<key>); bool key_up = key_state & ~new_key_state; bool key_down = new_key_state & ~key_state; bool key_toggled = key_state ^ new_key_state; // key_up | key_down key_state = new_key_state; }
Petit bonus pour l'entrée clavier, (left_key_down ^ right_key_down) = déplacement horizontal oui/non.
(PS: Le xor c'est puissant, domage qu'il n'existe pas d'opérateur ^^ en C !)

Ok, j'ai écrit ça de mon côté et ça marche :

void mouseWaitButtonRelease()
{
    while (1)
    {
        SDL_PollEvent(&events);
        if (events.type == SDL_MOUSEBUTTONUP)
            break;
    }
}

Mais t'as raison, c'est bloquant. Je vais faire beaucoup plus simple.

GoldenCrystal (./1446) :
domage qu'il n'existe pas d'opérateur ^^ en C !

...qui ferait quoi ? Le XOR est un opérateur binaire (au sens "2 opérandes" du terme).

Ben comme le && et le ||, sans la fonction court-circuitage (le xor est obligé d'évaluer les deux côtés donc bon… )
À savoir <a> ^^ <b> <=> ((<a>) != 0) ^ ((<b>) != 0)

Ah OK... je sais pas pourquoi, je pensais au ++, pas aux && et ||, je dois être fatigué. Effectivement, je me suis déjà posé la même question.

Folco (./1427) :
Comme ce n'était qu'un workaround pour éviter un warning, je n'y ai pas pensé. Merci bien.

Vouloir virer les warnings, c'est bien, essayer de le faire en changeant n'importe quoi sans comprendre, c'est très mal…

GoldenCrystal (./1449) :
Ben comme le && et le ||, sans la fonction court-circuitage (le xor est obligé d'évaluer les deux côtés donc bon… )
À savoir <a> ^^ <b> <=> ((<a>) != 0) ^ ((<b>) != 0)

Bah, !!a^!!b, ce n'est pas si long que ça.

Bien sûr, mais c'est bizarre que ça n'existe pas de base, c'eût été logique (et utile).

Kevin Kofler (./1451) :
Vouloir virer les warnings, c'est bien, essayer de le faire en changeant n'importe quoi sans comprendre, c'est très mal…

J'ai utilisée ta solution que j'ai très bien comprise...

Ce matin, mise en forme et nettoyage de ce que j'ai déjà fait en code, commentaires et compagnie.

Question utilisant votre expérience :
Les commentaires de fonctions, vous les mettez dans les sources, ou dans les headers ? Qu'est-ce qui est le plus commode ?
Je mets les commentaires et specs des structures dans les headers, mais je ne sais pas ce qui est le plus commode pour les fonctions.

(J'ose attendre que votre expérience parle pour m'aider, pas votre esprit de trollage )

Dans les sources. Je ne me souviens pas avoir vu des commentaires de fonctions dans des headers... C'est beaucoup plus pratique d'avoir le code à côté des commentaires.

Préférence personnelle, je dirais. Qu'est-ce qui t'arrange plus: pouvoir éditer les commentaires en même temps que le code, ou pouvoir les retrouver facilement quand tu veux te servir de ces fonctions ailleurs? Il y a aussi la solution de les mettre aux 2 endroits (les sources de ld-tigcc font ça, par exemple), mais personnellement je n'aime pas trop parce que ça fait 2 copies à éditer à chaque fois (mais je ne sais pas me décider laquelle des copies virer dans ld-tigcc, justement ).

Kevin Kofler (./1457) :
pouvoir éditer les commentaires en même temps que le code, ou pouvoir les retrouver facilement quand tu veux te servir de ces fonctions ailleurs?

C'est exactement el dileme que je me suis posé :
- d'un côté, si tes fonctions sont parfaitement fixées, elles ne changeront pas, donc un coup d'oeil dans le header te montrera plus facilement la fonction dont tu as besoin
- d'un autre côté, si tu veux changer la spec à un moment donné, ou pour faciliter le code, les commentaires dans les sources sont bien

Folco (./1455) :
Les commentaires de fonctions, vous les mettez dans les sources, ou dans les headers ? Qu'est-ce qui est le plus commode ?

Je mets toute la documentation dans les headers (je parle de la documentation Doxygen), et tous les commentaires propres au code, bah dans le code...

Je sais pas faire les commentaires Doxygen, faudra que je me penche dessus un jour, ça a l'air très puissant ^^

=> bookmarké : http://franckh.developpez.com/tutoriels/outils/doxygen/

Folco (./1458) :

Kevin Kofler (./1457) :
pouvoir éditer les commentaires en même temps que le code, ou pouvoir les retrouver facilement quand tu veux te servir de ces fonctions ailleurs?

C'est exactement el dileme que je me suis posé :
- d'un côté, si tes fonctions sont parfaitement fixées, elles ne changeront pas, donc un coup d'oeil dans le header te montrera plus facilement la fonction dont tu as besoin
- d'un autre côté, si tu veux changer la spec à un moment donné, ou pour faciliter le code, les commentaires dans les sources sont bien

Y'a une autre solution consistant à ne pas mettre 20 lignes de commentaire par fonction.
Si ton code est clair y'a pas besoin d'énormément de commentaires

Yay !

Aujourd'hui, j'ai pratiquement "rien fait" à part commenter et nettoyer mon code, corriger deux segfault, avoir le CPU à 7-8% en idle et non 100%.
On va réavancer ^^

Est-ce dangereux de passer un argument à une fonction qui n'en accepte pas a priori ?
je fais ça :
data->iconList[i].execOnClick((struct MODULE_DATA*) data);
Donc la fonction que j'appelle, je ne la connais que par son pointeur. Donc je n'ai pas de warning, alors que la majorité du temps, le proto de la fonction appelée diffère de celui écrit ici.

Quelles sont les conséquences ? J'imagine aucune, un argument est juste empilé avant puis dépilé après l'appel sans qu'il ne se passe autre chose ?

Il me semble qu'il existe des conventions d'appel dans lesquelles c'est à la fonction appelée de nettoyer la pile, donc si tu appelles une fonction supposée ne pas en accepter peut-être que ça va poser problème. Mais c'est une simple supposition, l'avis de quelqu'un qui s'y connait un peu serait le bienvenu ^^

Ok, attedons un autre avis. Sachant que dans mon cas, il va juste se passer que la fonction appelée ne nettoyera pas la pile, considérant qu'elle ne prend pas d'argument.

Ce genre de trucs sont absolument à éviter, si l'inliner de GCC se rend compte que tu fais ça, il te donne un warning à la compilation et un abort() quand ce code est exécuté.

PS: TIGCC est patché pour être plus tolérant envers ce genre de hacks, il désactive juste l'inlining dans ce cas (parce que ça planterait). Faudrait que je fasse un patchset pour GCC pour le rendre plus tolérant, un sous-ensemble portable du patch TIGCC.

si c'est une fonction externe en cdecl tu peux (et par defaut si t'es en C ou C++ c'est le cas), c'est au caller de nettoyer la stack (j'ai dit tu peux, mais pas forcement que c'est bien, je te laisse juge suivant le contexte )
les autres, que ce soit stdcall ou thiscall, c'est mort, c'est au callee de nettoyer la stack, donc tu te retrouvera avec une stack offsettee.

même si c'est l'appelant qui met un argument que l'appelé ne voit pas ? Que pourrait dégager une fonction dont le prototype ne lui dit pas qu'il y a un argument sur la pile ?

bah si elle attend rien, il se passe rien de special, elle va pas le chercher, c'est tout

et meme si t'as une fonction qui prend 3 parametres et que t'en passe 4, vu que le dernier parametre est push en premier (dans les calling conventions du C en tout cas, en delphi par exemple c'est dans l'autre sens il me semble), c'est pas genant, ca decalera pas ceux d'avant, et ta fonction accedera quand meme aux bons.

Ok, merci.