GameInput soit principalement conçu autour d’un modèle d’interrogation (polling), il existe des cas où il est préférable d’avertir les applications de façon asynchrone. Pour ce faire, 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 de sorte qu’un seul rappel s’exécute à 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 permet d’inscrire un maximum de 64 rappels, quel que soit leur type, à tout moment. 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 servent à détecter la connexion et la déconnexion des appareils, mais d’autres changements d’état peuvent aussi présenter un intérêt.enumerationKind accepte 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 façon bloquante ou asynchrone. La combinaison de l’énumération des appareils et des changements d’état subséquents 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 averties 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 les événements peut être préférable. Par exemple, l’interface utilisateur du menu principal d’un jeu peut être mieux adaptée à une entrée basée sur les événements. Un autre exemple est une interface utilisateur de mappage des entrées qui doit attendre une entrée après avoir invité l’utilisateur à faire 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 comprend à la fois les ressources utilisé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 bloque jusqu’à la fin de l’exécution du rappel. Par conséquent, un rappel ne peut pas se désinscrire lui-même à partir de sa propre fonction de rappel.
Les rappels peuvent aussi ê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é à partir de 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 finir par être désinscrits, car seulement 64 rappels sont autorisés à tout moment.