Author Topic: Acquisition clavier-souris: stratégies pour les applications temps réel  (Read 2662 times)

0 Members and 1 Guest are viewing this topic.

nystep

  • Guest
Donc bonjour le forum, bonjour tout le monde,

Je voulais vous demander vos expériences sur l'acquisition clavier souris dans le but d'en faire une entrée pour le gameplay d'un petit jeu...
J'ai donc cherché des infos sur direct input pour commencer, et je suis tombé sur cet article de microsoft:
http://msdn.microsoft.com/en-us/library/ee416842%28VS.85%29.aspx

Quote
This section provides information about the Microsoft DirectInput component of the Microsoft DirectX application programming interface (API). The DirectInput API is used to process data from a joystick, or other game controller. The use of DirectInput for keyboard and mouse input is not recommended, Windows messages should be used instead

Ah, ok alors, c'est tout bon: c'est ce que je faisais avant. Mais voilà: on peut quand même faire les choses mieux qu'avec la messagerie windows, par exemple, je pense au cas où il y a un lag qui arrive de façon aléatoire dans le jeu: typiquement avec les messages windows les entrées laggent aussi, j'ai l'impression de perdre le controle dans le jeu... Pire, si le lag s'éternise, j'ai envie d'appuyer sur échap et de pouvoir m'en sortir.. Mais il se peut que l'appli ne réponde pas. Par ailleurs, il se peut aussi que tous les messages d'entrée ne soit pas toujours transmis: exemple type dans mon jeu préféré (trackmania), les utilisateurs se retrouvent avec des problèmes comme celà: http://www.trackmania.com/fr/forum/viewtopic.php?t=27743&highlight=clavier+lag (je suppose que c'est des soucis du aux messages win32, mais difficile à dire comment ils ont implémenté dans ce cas précis).

D'où cette stratégie:

2 threads, un pour les entrées, et un pour le rendu. (j'en rajouterai un pour le réseau, plus tard). ça a peut être (sans doute) l'air stupide, mais voici la solution que j'imagine:

- thread d'entrées:
Code: [Select]
tant que le jeu tourne {
  WaitForSingleObject( mon_semaphore_préféré );
  dt = temps_présent - dernière_update;
  pour toutes les touches clavier possibles et imaginables {
    GetAsyncKeyState( toucheDuClavier ) blabla
    si(touche appuyée) état[toucheDuClavier] += dt;
  }
  ReleaseSemaphore( mon_semaphore_préféré );
  WaitForSingleObject( timer_periodique ); // 43Hz garantis en pratique si la granularitée demandée est trop fine! ;-)
}

- thread principal:

Il attend le sémaphore quand il a le temps d'update les entrées, essaie de faire un truc utile avec et remet les états à zéro... Bref. :)

Le but attendu c'est d'obtenir l'intégrale en temps (secondes) de l'appui d'une touche entre deux mises à jour des entrées...

voilà, discuss :)
« Last Edit: 30 November 2010 à 09:52:32 by nystep »

nystep

  • Guest
En ce qui concerne la souris, j'ai déjà trouvé cet excellent article... :)

http://msdn.microsoft.com/en-us/library/ee418864%28v=VS.85%29.aspx

ponce

  • Guest
Alors sous Windows j'utilise la message pump pour la souris et le clavier et aucun souci, dans le même thread qui update ma scene et tout.
J'avais pensé à threader la message pump mais bon ça nécessitait quelques efforts alors je suis resté avec ça et je n'ai pas de lag aléatoire donc pas les soucis dont tu parles.

nystep

  • Guest
ponce, j'ai également toujours utilisé le message pump comme toi jusqu'à maintenant.

J'essaie d'améliorer le procédé, car sous windows le message WM_KEYDOWN ne donne aucune indication du timestamp auquel la touche a été pressée, ce qui pénalise pour certains usages, comme dans ce cas faire l'intégrale du temps appuyé depuis la dernière mise à jour de l'état du clavier, afin d'avoir une qualité/précision meilleure et des applications nouvelles en termes de gameplay..

On peut récupérer effectivement la valeur du timer dans la procédure de callback, mais il s'agit du temps de réception du message alors, et non son temps d'émission... En cas de lag d'une seconde du rendu, tu te retrouves avec une petite centaine de message d'un coup...

Il ne faut pas oublier non plus que le multi-écran et le multitâche sont courants, ta fenêtre peut perdre des messages s'il y a une notification, où si l'utilisateur bascule de programme un peu n'importe quand... :)

Offline LittleWhite

La perte de contrôle d'une application (focus lost) devrait résulté à une mise en pause, simplement, non?

ponce

  • Guest
Quote
J'essaie d'améliorer le procédé, car sous windows le message WM_KEYDOWN ne donne aucune indication du timestamp auquel la touche a été pressée, ce qui pénalise pour certains usages, comme dans ce cas faire l'intégrale du temps appuyé depuis la dernière mise à jour de l'état du clavier, afin d'avoir une qualité/précision meilleure et des applications nouvelles en termes de gameplay..
Oui je vois que ça pourrait être meilleur, enfin bon c'est "good enough" pour moi, j'ai d'autres problèmes à régler dans mes jeux avant en principe :)

Cela dit il me semble avoir vu quelque part que DirectInput était bien pour le clavier.