GameInput soit principalement conçu autour d’un modèle d’interrogation (polling), il existe des cas où il est préférable de notifier les applications de manière asynchrone. Pour cela, l’interface IGameInput expose quelques méthodes permettant d’inscrire des fonctions de rappel qui sont appelées lorsque certains événements d’intérêt se produisent.
En interne, GameInput sérialise la distribution des rappels afin qu’un seul rappel soit exécuté à la fois. GameInput garantit que les rappels sont distribués dans l’ordre chronologique. Ces garanties simplifient le code qu’une application doit écrire dans ses fonctions de rappel.
GameInput autorise l’inscription d’un maximum de 64 rappels à un moment donné, quel que soit leur type. Les rappels sont distribués à partir d’un thread de travail interne de GameInput. Pour plus d’informations sur ce fonctionnement, ainsi que sur les options permettant de planifier manuellement ce travail, consultez Files d’attente de travail GameInput.
Rappels d’appareil
Les rappels d’appareil permettent aux applications de savoir quand l’état des périphériques d’entrée change, comme le montre la syntaxe suivante. Le plus souvent, ils sont utilisés pour détecter la connexion et la déconnexion des appareils, mais d’autres changements d’état peuvent également présenter un intérêt.enumerationKind prend une valeur de l’énumération GameInputEnumerationKind, qui indique si l’énumération doit être effectuée dans le cadre de l’inscription du rappel et, le cas échéant, si elle doit être effectuée de manière bloquante ou asynchrone. Combiner l’énumération des appareils et les changements d’état ultérieurs en une seule opération atomique évite les conditions de concurrence dont souffrent involontairement de nombreuses applications dans leur code d’entrée.
Rappels de lecture
Grâce aux rappels de lecture, les applications peuvent être notifiées chaque fois que de nouvelles lectures arrivent dans le flux d’entrée, comme le montre la syntaxe suivante. Bien que de nombreuses applications trouveront préférable d’interroger les entrées, il existe des situations où une entrée basée sur des événements peut être plus appropriée. Par exemple, l’interface utilisateur du menu principal d’un jeu peut être mieux adaptée à une entrée basée sur des événements. Un autre exemple est une interface de mappage des entrées qui doit attendre une entrée après avoir invité l’utilisateur à effectuer sa sélection.Désinscription des rappels
Une fois qu’un rappel a été inscrit avec succès, l’application doit garantir que toutes les ressources nécessaires à l’exécution du rappel restent valides. Cela inclut à la fois les ressources consommées par le code du rappel et la fonction de rappel elle-même, par exemple si la fonction de rappel est hébergée dans une DLL que l’application charge et décharge à la demande. Pour récupérer ces ressources en toute sécurité, une application doit d’abord désinscrire le rappel en passant le jeton reçu de la méthodeRegister*Callback à la méthode UnregisterCallback. Si le rappel est en cours d’exécution lorsque cette méthode est appelée, celle-ci est bloquée jusqu’à la fin de l’exécution du rappel. Par conséquent, un rappel ne peut pas se désinscrire lui-même depuis sa propre fonction de rappel.
Les rappels peuvent également être arrêtés en appelant la méthode StopCallback. Celle-ci ne désinscrit pas le rappel, mais garantit qu’il ne sera plus appelé. Comme le rappel n’est pas désinscrit, cette méthode peut être appelée en toute sécurité depuis la propre fonction de rappel d’un rappel. Elle termine l’exécution du rappel en cours, mais ne l’appelle plus. Les rappels doivent finalement être désinscrits, car seuls 64 rappels sont autorisés à un moment donné.