Discussion :

[Mark53]

Bonjour à tous,

Je suis face à un problème classique. Je scrute le clavier avant chaque génération de frame (environ toutes les 30 ms) avec GetDeviceState. Quand l'utilisateur presse une touche, elle peut rester enfoncée pendant 1/4 de seconde, par exemple, ce qui fait que le scruteur l'intercepte plusieurs fois et déclenche plusieurs fois le handler approprié... D'où le problème. J'ai essayé de bufferiser l'accès au clavier avec GetDeviceData mais ça n'a pas solutionné le problème. De plus, comment gérer justement le fait que la touche reste enfoncée plusieurs secondes ? La seule méthode que j'ai trouvée pour résoudre partiellement le problème est de créer artificiellemetn un délai entre 2 scrutations du clavier successives, mais du coup, le jeu n'est plus très réactif aux impulsions du clavier, ce qui crée un autre problème.

Ceux qui ont créé des jeux vidéo, comment avez-vous géré ce problème classique ?

Merci d'avance,
Mark

[Laurent Gomila]

De mémoire je crois qu'il y a un mode à spécifier pour que DirectInput gère l'appui de touches "façon Windows" (càd avec un délai avant répetition), mais je ne me souviens vraiment plus ce que c'est. Tu as regardé les samples du SDK ?

[Mark53]

Salut Loulou,

Merci pour ta réponse. En fait, je n'ai pas d'exemple dans mon SDK, mais je me suis inspiré des fichiers d'aide de DirectX 7 et d'exemples sur le Net. Mais je me dis qu'il y a forcément d'autres développeurs qui ont rencontré ce problème... Si tu fais une recherche sur google, tu vas voir que le sujet est largement abordé... Le problème est que je n'arrive pas à trouver de réponse. En fait, j'aimerais gérer à la fois la frappe d'une touche et le fait que la touche reste enfoncée...

Allez, à plus,
Mark

[olivic]

En faites, tu as deux évènements que l'on peut récupérer.

Le moment où une touche est enfoncée et le moment où une touche est relachée. Pour du ponctuel, on utilise plutôt le moment où une touche est relachée.

Ex : clique sur un bouton avec ta souris en maintenant le bouton. Tu contateras que l'évènement associé n'est activé que lorsque tu relacheras le bouton de la souris mais seulement si tu es encore sur le bouton.

A partir de ces deux évènement tu peux aussi créer des animations syncroniser si celles-ci se base sur le temps qui s'écoule.

Ex : la touche est enfoncé => le temps s'écoule => l'animation se déroule en fonction du temps qui s'est passé depuis la dernière scutation.
la touche est relaché => le temps ne s'écoule plus => l'animation est stopée.

[Mark53]

Salut olivic,

Merci à toi pour ton aide. En effet, c'est une bonne idée de déclencher un événement uniquement quand le bouton est relâché. Mais alors comment gérer le fait que le bouton est appuyé longtemps ? Si on se base sur le même principe, l'événement sera activé bien trop tard...

Pensez aux jeux vidéos qui existent. Prenons Mario. Vous appuyez sur la droite, et le bonhomme fait juste un pas vers la droite. Maintenez le bouton enfoncé, et il va courir... Hé bien c'est exactement le résultat que j'aimerais obtenir ! Pas facile...

Bonne soirée,
Mark

[Laurent Gomila]

Si vraiment tu ne trouves pas comment faire avec l'API, tu peux toujours mettre une temporisation toi-même lors de l'appui sur une touche et ne pas générer d'évènement pendant ce laps de temps, puis lorsqu'il est ecoulé générer l'évènement en continu. Bien sûr si entre temps la touche a été relâchée, il faut tuer la tempo et la relancer. Enfin voilà c'est l'idée, pour les détails je te laisse voir .

[LeGreg]

Ton clavier fonctionne de deux façons dans DInput

L'une par état, qui t'indique simplement si la touche est en ce moment enfoncée ou pas mais qui n'indique pas depuis quand elle est enfoncée ni l'ordre dans lesquelles elles sont enfoncées.

La deuxième par évènement, qui indique : "la touche est entrée dans l'état enfoncé à telle date" puis "la touche est sortie de l'état enfoncée à telle date" mais qui nécessite de maintenir le buffer de manière précise pour chaque touche utilisé (alors qu'avec l'autre méthode tu peux ne sonder que la touche qui t'interesse à l'instant t).

Dans un des programmes que j'avais écrit, je faisais simplement un "polling" de l'état des touches à intervalle régulier. Tant que la touche "avant" était enfoncée, le mouvement "vers l'avant" était actif, tu peux mémoriser l'historique des sondages précédents pour dire que si pendant x ms la touche est toujours enfoncée, alors on va passer de l'état marcher à l'état courir.

L'inconvénient de la méthode "état" c'est que tu n'es pas sur que la touche n'est pas passée de l'état enfoncé à pas enfoncé alors que tu faisais autre chose (affichage ou gestion de l'IA). Dans mon cas ce n'etait pas un probleme parce que le sondage était suffisamment fréquent (framerate élevé) et l'action à l'écran était basée sur la durée de pression plus que sur la précision du nombre d'appuis successifs.
Par contre si tu veux un jeu ou le framerate est faible, ou encore si tu veux capter une frappe de texte au clavier, il est indispensable que tu utilises le mode par évenements, ne serait-ce que pour l'ordre d'arrivée des éenévnmtes dnas le cas cnortiare tu aruias du mal à reconstruire le signal.

[olivic]

Dans ce cas là, il faut utiliser la deuxième solution que je t'ai donné.

Je réexplique :
Tu appuis sur la touche droite.
On applique donc une fonction de déplacement sur le personnage de Mario.
Tu relache la touche droite.
On arrête la fonction de déplacement du personnage.

La fonction de déplacement doit être en fonction du temps. Ce temps est le temps qui c'est écoulé pendant l'exécution complète de ta boucle d'évènement.

De manière mathématique :
d = v/t avec t != 0
d : la distance que doit parcourir on personnage => ta matrice de déplacement.
v : la vitesse que tu veux appliquer à ton personnage.
t : le temps qui s'est écoulé

Par contre, il existe un petite chose en plus dans le cadre des jeux. Tu disais que Mario marche au début puis se met progressivement à courrir.
Mais il y a aussi le fait que Mario se met à glisser avant de s'arrêter.

En définitive, la vitesse est variable ; c'est donc une accélération.
Donc il faut rajouter d = a * t².

En conclusion on a :
d = v / t + a * t² avec t != 0

Explication supplémentaire :
Quand par exemple tu appuis sur la touche courrir, v est remplacer par un autre v qui à une valeur plus élevé (et inversement).

a doit obligatoirement varier en fonction du temps. Sinon, tu te retrouve à avoir un accélération infini. On le fixe à 1 (accélération de départ) à l'appui sur la touche droite, puis on l'augmente progressivement jusqu'à 2 au bout de 20ms. Et inversemment à l'arrêt du personnage ; on supprime la vitesse et on réduit l'accélération emganiser.

Par exemple, si tu augmentes la valeur d'accélération finale pour les valeurs d'accélération ainsi que le temps d'amorti, tu peux faire glisser ton personnage.

Par contre, tu as du remarquer que quand tu lâches la touche, l'animation va continuer un certain temps. Il va donc falloir utiliser les Thread (ou des Timer).

Je n'ai jamais eu le temps d'implémenter cet algorithme donc de ce coté là, je te souhaites bonne chance.

[LeGreg]

En gros, ça ferait un truc comme:

tu aurais une variable locale que tu initialiserais à zéro
qui s'appelerait "WalkingForMilliseconds".
Lors du premier sondage, tu détectes la touche avant enfoncée.
Tu mets WalkingForMilliseconds à une valeur arbitraire et tu signales au reste du programme que tu commences à marcher.
Au deuxième sondage, la touche avant est toujours enfoncée,
"WalkingForMilliseconds" est augmentée du montant nécessaire et au bout de x passages quand ""WalkingForMilliseconds" dépasse le montant que tu t'es fixé, tu passes au reste du programmes l'info comme quoi tu t'es mis à "courir".

Aux sondage suivant, la touche n'est pas détectée comme enfoncée, tu remets "WalkingForMilliseconds" à zéro et tu signales au reste du programme que tu as arréte de marcher et de courir.

Après tu customises en fonction de tes besoins..

[LeGreg]

Par contre, tu as du remarquer que quand tu lâches la touche, l'animation va continuer un certain temps. Il va donc falloir utiliser les Thread (ou des Timer)..

Il n'est vraiment pas nécessaire de faire appel aux threads ni aux timers,
ta boucle de jeu suffit.
Le thread ou le timer est a reserver aux choses vraiment plus complexes. (comme gérer les appels bloquants sur le disque ou sur le réseau, tirer parti du multiprocessing etc..).