Détecter l'appuies sur une touche [SDL] - C - Programmation
Marsh Posté le 20-01-2010 à 13:02:30
Je ne vois pas trop à quoi te sert le passage d'évènement par valeur à ta fonction quitterOuEchap, sinon, ca m'a l'air ok.
Tu peux poser des breakpoints pour voir si tu arrives dans les fonctions qui t'intéressent et tracer ...
Est-ce que tu passes au moins dans ta fonction, déjà ? Parce que le code que tu ne nous montre pas pourrait bien contenir un continue qui va te la faire éviter ou quelque chose du genre.
Marsh Posté le 20-01-2010 à 15:48:46
Hmm, j'imagine qu'il s'agisse du même programme que celui que tu as posté ici : http://forum.hardware.fr/hfr/Progr [...] 7182_1.htm
Parce que si c'est ça, ton problème se situe dans la fonction "appuisSurV()" dans lequel tu fais déjà un SQL_PollEvent, ce qui fait que la fonction suivante "quitterOuEchap()" n'aura plus rien à se mettre sous dent.
Arf, et je vois que fait une boucle d'attente avec un délai de 5ms (200 fps quand même). Sous Windows, si tu veux un délai aussi court, faut y aller bourrin, à coup de "while(getticks() - old < 5);". Les timer sous Windows on une précision de 10 à 15ms, soit tout juste bon pour faire du 50 à 60 fps.
Edit: je viens de voir plus en détail ta gestion des événements, et c'est pas trop ça. En général on ne fait qu'un seul appel à SQL_PollEvent ou SQL_WaitEvent et un seul switch sur "event.type". Après tu peux appeler d'autres fonctions dans les branches du switch.
Marsh Posté le 20-01-2010 à 17:53:47
Oui c'est bien le même programme.
Pour l'attente en fait je modifie la valeur en fonction du nombre de calculs que le programme doit effectuer. Ca me sert juste à ralentir le programme histoire de ne pas aller trop vite, et donc je m'en fiche de la précision.
Pour l'appel à SDL_WaitEvent, je le fais quand ?
Avant le while ?
Après je fais juste un switch sur event.type dans le while (donc dans ma fonction) ?
Marsh Posté le 20-01-2010 à 19:48:13
tpierron a écrit : |
Mince j'ai lu trop rapidement et j'ai omis cette partie du message.
C'est effectivement ça, mais alors comment faire ?
Marsh Posté le 20-01-2010 à 20:40:43
Bah c'est pas compliqué pourtant, il faut qu'il n'y ait qu'un seul appel à SDL_PollEvent() dans tout ton programme.
Donc appel cette fonction une seule fois et transmert la structure "event" à tes fonctions appuisSurV() ou quitterOuEchap(), du style (main.c) :
Code :
|
Et enlève évidemment l'appel à SDL_PollEvent() dans les deux sous fonctions.
Marsh Posté le 20-01-2010 à 21:23:44
tpierron a écrit : Bah c'est pas compliqué pourtant, il faut qu'il n'y ait qu'un seul appel à SDL_PollEvent() dans tout ton programme.
|
Magnifique, merci infiniment
Marsh Posté le 21-01-2010 à 10:41:29
Une autre question, comment on utilise le débogueur de Code::Blocks ?
Dans projet->Build option j'ai bien coché "Produce debugging symbols" et j'ai mis un ponit d'arrêt dans le programme, mais quand je compile en lance en debug le logiciel ce lance normalement, il ne s'arrête pas au point d'arrêt....
Parce que j'ai un bug et je comprend vraiment pas d'où il vient......
Si vraiment je le trouve pas je posterais les sources mis à jour peut-etre que vous pourrez encore me sauver.
Marsh Posté le 21-01-2010 à 13:03:03
Tu as une barre d'outils debugger avec des boutons lancer, pas à pas, etc
Marsh Posté le 21-01-2010 à 13:07:41
ptitchep a écrit : Tu as une barre d'outils debugger avec des boutons lancer, pas à pas, etc |
Oui je sais, pour lancer je clique sur le bouton Debug/Continue mais ça me lance simplement le programme sans s'arrêter au point d'arrêt
Marsh Posté le 21-01-2010 à 14:43:42
Cpowa a écrit : |
ou tu ne mais pas de break-point
ou le code ne passe pas de cette break-point
avis personel (ne prener pas ca du coté negative) :
je vois quelque faiblaisse dans le program
meme si ca va marcher , il va te fatiguer
mieux avoir les chose plus simple et claire
(les nom de function, l'organization ... etc)
...
Marsh Posté le 21-01-2010 à 15:28:04
__tomjost a écrit : |
le ponit d'arrêt est mis.
Et le code passe forcément par main .
__tomjost a écrit : |
oui là il est pas terminé, j'ai peaufiner et commenté.
Mais il me reste ce satané bug
Marsh Posté le 21-01-2010 à 15:48:37
quelque description de ce bug ?
quesqui ne marche pas ?
la ligne (ou 3) ou tu mais un break point ?
...(j'attend 5 minutes et je quitte )
Marsh Posté le 21-01-2010 à 16:48:43
Quand je met un point d'arrêt et que je clique sur Debug/Continue, ça me lance le programme et me grise toutes les commandes du debug (je ne peux plus cliquer dessus) et le programme ignore totalement le point d'arrêt.
Pour le bug j'explique le principe du programme:
Il simule l'évolution d'une boule accroché à un ressort (c'est comme un pendule sauf qu'on change la corde par un ressort).
Donc au début j'affiche la boule avec son ressort qui bougent, puis quand on appuye sur espace on passe dans le mode "trace". C'est à dire qu'on trace la trajectoire de la boule.
Tout fonctionne quand je met une masse.
Mais quand je met plus d'une masse, au début ça fonctionne je vois mes masses évoluer avec leurs ressorts. Mais quand je passe en mode trace j'obtiens une trajectoire tout droite, et je ne comprend pas pourquoi. Parce que le mode trace est exactement comme l'autre mode sauf qu'au lieu d'afficher la boule et le ressort, puis d'effacer l'écran, ré afficher la boule et le ressort effacer l'écran etc... et bien on affiche seulement un pixel à l'endroit de la boule sans effacer l'écran.
Que les deux modes ne fonctionnent pas ce serait compréhensible mais que seul le mode trace bug je ne comprend pas...
Je post mes sources à jour (sauf les header qui servent à rien). (attentions certains commentaires ne sont pas bon j'ai pas encore tout commenté)
main.c
Code :
|
graphique.c
Code :
|
evenement.c
Code :
|
Marsh Posté le 21-01-2010 à 17:53:58
Cpowa a écrit :
|
C'est quoi continuer1 et continuer2
Pourquoi dans ta boucle principale tu as 2 while non imbriqué? (parce que la ca fait 2 boucles...)
Marsh Posté le 21-01-2010 à 17:59:41
Première boucle: affichage normal
Deuxième boucle: affichage en mode trace.
Donc les deux boucles sont identiques sauf que dans l'une on affiche que des pixels.
continuer1 et continuer2 pour pouvoir sortir des deux boucles si on veut quitter le programme.
Marsh Posté le 21-01-2010 à 20:20:56
Cpowa a écrit : Une autre question, comment on utilise le débogueur de Code::Blocks ? |
ptitchep a écrit : Tu as une barre d'outils debugger avec des boutons lancer, pas à pas, etc |
Dev-Cpp
Sinon j'ai le même problème perso, la barre d'outils qui s'appelle "Debug" sous Code::Blocks contient des élements grisés (tout le temps), et le programme ne s'arrête pas aux points d'arrêt.
Marsh Posté le 21-01-2010 à 22:33:45
c'est peut etre un composant du coordonne qui prend zero...
pour les break-point:
tout simplement , il n'ya pas debug-info , ni symbol ni text!
je ne connait pas ce "Dev-Cpp" mais
voir si il ya d'autre option qui controle ca ,
on choisie le type du debug ...etc
Marsh Posté le 22-01-2010 à 10:42:53
Je n'ai jamais rien debuggé dans code::blocks, même si je l'utilise pour coder. Ca n'a jamais vraiment marché correctement: il ignorait des points d'arret pour moi aussi et même parfois freezait completement, par exemple avec des programmes OpenGL... Je pense que cela vient d'une utilisation bizarre de gdb car je n'ai pas de problème avec d'autre debuggers.
Sous Linux j'ai kdbg qui ne tourne pas trop mal mais n'importe quelle couche graphique de gdb fait l'affaire(hors code::blocks ). Sous Windows, je n'ai pas de solution. Les rares fois où j'en ai besoin j'utilise visual studio et je dois reconnaitre que le peu que j'en ai vu le place pour moi n°1 des debugger.
Marsh Posté le 20-01-2010 à 12:57:32
Bonjour,
J'ai un code tu type:
Avec la fonction quitterOuEchap:
Malheureusement j'ai beau marteler la touche échap ou m'exciter sur la croix ça quitte pas, vous savez pourquoi ?
Merci.