GameInput は主にポーリングモデルを中心に設計されていますが、アプリケーションに非同期で通知することが最適な場合もあります。これをサポートするため、IGameInput インターフェイスは、対象となる特定のイベントが発生したときに呼び出されるコールバック関数を登録するためのいくつかのメソッドを公開しています。
内部的に、GameInput はコールバックのディスパッチをシリアル化し、一度に 1 つのコールバックのみが実行されるようにします。GameInput は、コールバックが時系列順にディスパッチされることを保証します。これらの保証により、アプリケーションがコールバック関数内に記述する必要のあるコードが簡素化されます。
GameInput は、種類にかかわらず、任意の時点で最大 64 個のコールバックを登録できます。コールバックは GameInput の内部ワーカースレッドからディスパッチされます。この動作の詳細、およびこの作業を手動でスケジュールするオプションについては、GameInput ワークキュー を参照してください。
デバイスコールバック
デバイスコールバックは、次の構文に示すように、入力デバイスの状態が変化したことをアプリケーションに知らせる方法を提供します。最も一般的には、デバイスの接続と切断を検出するために使用されますが、その他の状態変化も対象となる場合があります。enumerationKind パラメーターは GameInputEnumerationKind 列挙型の値を受け取り、列挙をコールバック登録の一部として行うかどうか、そしてその場合はブロッキング方式と非同期方式のどちらで行うかを示します。デバイス列挙とその後の状態変化を単一のアトミック操作に組み合わせることで、多くのアプリケーションが入力コード内で意図せず被る競合状態を回避できます。
読み取りコールバック
読み取りコールバックを使用すると、次の構文に示すように、新しい読み取りが入力ストリームに到着したときにアプリケーションに通知できます。多くのアプリケーションでは入力をポーリングする方が適していますが、イベント駆動型入力の方が望ましい状況もあります。たとえば、ゲームのメインメニュー UI はイベントベースの入力の方が適している可能性があります。もう 1 つの例は、ユーザーに選択を促した後に入力を待つ必要がある入力マッピング UI です。コールバックの登録解除
コールバックが正常に登録された後、アプリケーションはコールバックの実行に必要なリソースが有効なまま保持されることを保証する必要があります。これには、コールバックのコードが使用するリソースと、コールバック関数自体の両方が含まれます。たとえば、アプリケーションが必要に応じてロードおよびアンロードする DLL 内にコールバック関数がホストされている場合などです。 これらのリソースを安全に再要求するには、アプリケーションはまず、Register*Callback メソッドから受け取ったトークンを UnregisterCallback メソッドに渡してコールバックの登録を解除する必要があります。このメソッドが呼び出されたときにコールバックが実行されている場合、コールバックの実行が完了するまでブロックされます。その結果、コールバックが自身のコールバック関数内から自身の登録を解除することはできません。
コールバックは、StopCallback メソッドを呼び出すことで停止することもできます。これはコールバックを登録解除しませんが、コールバックが再度呼び出されないようにします。コールバックが登録解除されないため、このメソッドはコールバック自身のコールバック関数内から安全に呼び出すことができます。現在のコールバックの実行を完了しますが、それを再度呼び出しません。同時に許可されるコールバックは 64 個のみであるため、コールバックは最終的には登録解除する必要があります。