> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # Notions fondamentales de GameInput > Notions fondamentales de GameInput La plupart des anciennes API d'entrée de Microsoft sont centrées sur les périphériques, ce qui signifie que le code de l'application doit d'abord trouver les périphériques d'entrée qu'il prend en charge, généralement au moyen d'un modèle d'énumération, avant de pouvoir lire des entrées. Pour la plupart des jeux ayant des besoins d'entrée relativement simples, cela ajoute beaucoup de code et de complexité. L'API GameInput, en revanche, est centrée sur les entrées. Les applications trouvent d'abord les entrées qui les intéressent, puis peuvent facultativement interroger le périphérique qui a généré l'entrée. Cela mène à des algorithmes plus naturels, et donc à un code plus simple. ## Architecture du flux d'entrée GameInput est construit autour du concept de flux d'entrée : les entrées de tous les périphériques connectés au système sont dirigées vers un seul flux contigu d'événements d'entrée, dans l'ordre où les entrées se sont produites. Lorsque plusieurs périphériques génèrent des entrées simultanément, il en résulte un entrelacement naturel des événements d'entrée. Voici un exemple de flux d'entrée provenant de plusieurs périphériques d'entrée. Exemple de flux d'entrée provenant de plusieurs périphériques d'entrée Dans cet exemple, quatre périphériques envoient des entrées simultanément. Le numéro de chaque carré représente l'ordre dans lequel l'entrée a été envoyée, et la couleur représente le périphérique qui a envoyé l'entrée. Ainsi, dans cet exemple, la première manette envoie la première entrée, le clavier envoie la deuxième, la souris envoie la troisième et la deuxième manette envoie la quatrième. Chaque élément du flux d'entrée est représenté par une « lecture ». Les applications commencent par obtenir la lecture la plus récente du flux d'entrée. À partir de là, l'application peut soit continuer à obtenir périodiquement la lecture la plus récente, soit parcourir le flux d'entrée vers l'avant et vers l'arrière en examinant les lectures adjacentes. Dans les deux cas, l'application compare généralement les différences entre les lectures qui l'intéressent, puis prend les mesures appropriées. Par exemple, un jeu de tir à la première personne pourrait n'avoir besoin de savoir que si un bouton est enfoncé au début de chaque image pour déterminer si l'arme du joueur doit tirer. Dans ce cas, seule la lecture la plus récente compte (et toutes les lectures intermédiaires peuvent être ignorées). En revanche, un jeu de combat compétitif pourrait vouloir examiner chaque changement d'état d'entrée survenu entre l'image précédente et l'image actuelle pour l'une ou l'autre des raisons suivantes. * Appuyer deux fois rapidement sur un bouton pourrait correspondre à un combo ou à un mouvement différent d'un appui simple. * L'ordre dans lequel deux boutons ont été enfoncés pourrait être important. * Le temps écoulé entre deux appuis sur des boutons pourrait être important. Lors de la récupération des lectures du flux d'entrée, les applications peuvent appliquer des filtres facultatifs, qui limitent les résultats aux lectures de types d'entrée précis (comme les manettes ou les claviers) ou d'un périphérique précis, ou les deux. Pour plus de détails, consultez [Lectures GameInput](/fr-CA/build/core-features/common/input/overviews/input-readings). Les applications ne peuvent demander que les lectures historiques du flux d'entrée survenues au cours de la dernière demi-seconde. La lecture la plus récente de chaque périphérique connecté est toujours accessible, peu importe son âge. ## Interfaces L'API GameInput est exposée au moyen d'une collection d'interfaces connexes, à l'instar des API graphiques et audio, comme le montre le diagramme suivant. Diagramme de l'API GameInput exposée au moyen d'une collection d'interfaces connexes Trois interfaces principales constituent l'essentiel de la surface de l'API GameInput. * [`IGameInput`](/fr-CA/reference/input/gameinput/interfaces/igameinput/igameinput) est l'interface de base obtenue en appelant la fonction de fabrique [`GameInputCreate`](/fr-CA/reference/input/gameinput/functions/gameinputcreate). Elle contient des méthodes pour récupérer les lectures du flux d'entrée, inscrire des rappels et accéder à d'autres fonctionnalités globales. * [`IGameInputReading`](/fr-CA/reference/input/gameinput/interfaces/igameinputreading/igameinputreading) représente un seul élément du flux d'entrée. Elle contient des méthodes pour récupérer les données d'état d'entrée stockées dans la lecture et pour accéder au périphérique qui a généré la lecture. Les lectures servent aussi de points de référence dans le flux d'entrée lors du parcours vers l'avant et vers l'arrière des autres lectures du flux. * [`IGameInputDevice`](/fr-CA/reference/input/gameinput/interfaces/igameinputdevice/igameinputdevice) représente un seul périphérique d'entrée connecté au système. Elle contient des méthodes pour récupérer les propriétés et l'état actuel du périphérique, ainsi que des méthodes pour contrôler la rétroaction haptique et la rétroaction de force sur le périphérique. Elle contient aussi des méthodes pour effectuer des E/S brutes de bas niveau sur le périphérique. Les autres interfaces sont utilisées dans des contextes précis, qui sont abordés dans la section [Rubriques avancées sur GameInput](/fr-CA/build/core-features/common/input/advanced/input-advanced-topics). Comme les API graphiques et audio, GameInput n'est pas une véritable API COM, même si elle expose des interfaces dérivées de IUnknown. Ce style d'API est parfois appelé « COM lite » ou « nano-COM ». Bien que IUnknown soit utilisé pour le décompte de références et la réflexion, l'infrastructure du runtime COM n'est pas utilisée par GameInput. Plus précisément, cela signifie ce qui suit. * Les applications n'appellent ni `CoInitialize` ni `CoCreateInstance` pour obtenir des instances d'objets. * Les fonctionnalités COM comme l'agrégation et les implémentations d'interfaces fournies par l'appelant ne sont pas prises en charge. * Il n'y a aucune prise en charge du marshaling entre processus, ni de modèle d'apartment ou de threading. Tous les objets sont agiles. * Les pointeurs d'interface peuvent être comparés directement pour déterminer l'identité des objets, sans passer par IUnknown. * Les méthodes ne sont pas tenues de retourner des codes `HRESULT`, ce qui mène souvent à des signatures de fonctions plus simples. ## Focus de l'application Sur console, GameInput fournit des entrées à une application uniquement lorsqu'elle a le focus. Sinon, l'état retourné contient des valeurs neutres ou « au repos », comme si l'utilisateur ne touchait pas du tout le périphérique. Cela élimine le besoin de code d'entrée supplémentaire pour gérer les changements de focus. Sur PC, par défaut, les entrées (y compris les boutons système) sont envoyées aux applications qui ont le focus. Ce comportement peut être modifié à l'aide de la méthode [SetFocusPolicy](/fr-CA/reference/input/gameinput/interfaces/igameinput/methods/igameinput_setfocuspolicy). Toute rétroaction haptique ou rétroaction de force envoyée à un périphérique est désactivée lorsqu'une application perd le focus. L'application peut toujours appeler les API GameInput pour définir un nouvel état de rétroaction, mais ce nouvel état ne sera pas envoyé au périphérique. Lorsque l'application retrouve le focus, le plus récent état de rétroaction demandé par l'application est automatiquement envoyé au périphérique. Par conséquent, les applications n'ont aucune action particulière à effectuer concernant les entrées ou la rétroaction haptique ou de force lorsqu'elles obtiennent ou perdent le focus. L'API GameInput fait toujours ce qu'il faut en leur nom. ## Documentation de référence de l'API * [GameInput (contenu de l'API)](/fr-CA/reference/input/gameinput/gameinput_members) * Fonctions * [gameinputcreate](/fr-CA/reference/input/gameinput/functions/gameinputcreate) ## Voir aussi [Lectures GameInput](/fr-CA/build/core-features/common/input/overviews/input-readings) [Périphériques GameInput](/fr-CA/build/core-features/common/input/overviews/input-devices) [Rubriques avancées sur GameInput](/fr-CA/build/core-features/common/input/advanced/input-advanced-topics) [Référence de l'API GameInput](/fr-CA/reference/input/gc-reference-input-toc) ## Related topics - [Lecturas de GameInput](/es/build/core-features/common/input/overviews/input-readings.md) - [Portabilidad de XInput a GameInput](/es/build/core-features/common/input/porting/input-porting-xinput.md) - [Información general de GameInput](/es/build/core-features/common/input/overviews/input-overview.md) - [Temas avanzados de GameInput](/es/build/core-features/common/input/advanced/input-advanced-topics.md) - [Devoluciones de llamada de GameInput](/es/build/core-features/common/input/advanced/input-callbacks.md)