GameInput은 기본적으로 폴링 모델을 중심으로 설계되었지만, 애플리케이션에 비동기적으로 알리는 것이 더 적합한 경우도 있습니다. 이를 지원하기 위해 IGameInput 인터페이스는 특정 관심 이벤트가 발생할 때 호출되는 콜백 함수를 등록하기 위한 몇 가지 메서드를 제공합니다.
내부적으로 GameInput은 한 번에 하나의 콜백만 실행되도록 콜백 디스패치를 직렬화합니다. GameInput은 콜백이 시간순으로 디스패치됨을 보장합니다. 이러한 보장 덕분에 애플리케이션이 콜백 함수에서 작성해야 하는 코드가 단순해집니다.
GameInput은 유형에 관계없이 언제든지 최대 64개의 콜백을 등록할 수 있게 합니다. 콜백은 GameInput의 내부 워커 스레드에서 디스패치됩니다. 이 동작 방식과 이 작업을 수동으로 예약하는 옵션에 대한 자세한 내용은 GameInput 작업 큐를 참조하세요.
장치 콜백
장치 콜백은 다음 구문과 같이 입력 장치의 상태가 변경될 때 애플리케이션이 이를 알 수 있는 방법을 제공합니다. 가장 일반적으로는 장치의 연결 및 연결 해제를 감지하는 데 사용되지만, 다른 상태 변경도 관심 대상이 될 수 있습니다.enumerationKind 매개 변수는 GameInputEnumerationKind 열거형의 값을 취하며, 콜백 등록의 일부로 열거를 수행할지 여부와, 수행한다면 블로킹 방식으로 할지 비동기 방식으로 할지를 나타냅니다. 장치 열거를 이후의 상태 변경과 하나의 원자적 작업으로 결합하면 많은 애플리케이션이 입력 코드에서 의도치 않게 겪는 경합 상태를 피할 수 있습니다.
판독값 콜백
판독값 콜백을 사용하면 다음 구문과 같이 입력 스트림에 새 판독값이 도착할 때마다 애플리케이션에 알림을 받을 수 있습니다. 많은 애플리케이션에서는 입력을 폴링하는 것이 더 나을 수 있지만, 이벤트 기반 입력이 더 적합한 상황도 있습니다. 예를 들어 게임의 메인 메뉴 UI는 이벤트 기반 입력에 더 적합할 수 있습니다. 또 다른 예는 사용자에게 선택을 요청한 뒤 입력을 기다려야 하는 입력 매핑 UI입니다.콜백 등록 해제
콜백이 성공적으로 등록된 후에는, 애플리케이션이 콜백을 실행하는 데 필요한 모든 리소스가 유효한 상태로 유지되도록 보장해야 합니다. 여기에는 콜백 코드에서 사용하는 리소스뿐만 아니라 콜백 함수 자체도 포함됩니다. 예를 들어, 콜백 함수가 애플리케이션이 필요에 따라 로드하고 언로드하는 DLL에 호스팅되는 경우입니다. 이러한 리소스를 안전하게 회수하려면, 애플리케이션이 먼저Register*Callback 메서드에서 받은 토큰을 UnregisterCallback 메서드에 전달하여 콜백을 등록 해제해야 합니다. 이 메서드를 호출할 때 콜백이 실행 중이면 콜백 실행이 완료될 때까지 블록됩니다. 그 결과, 콜백은 자신의 콜백 함수 내에서 자기 자신을 등록 해제할 수 없습니다.
콜백은 StopCallback 메서드를 호출하여 중지할 수도 있습니다. 이렇게 하면 콜백이 등록 해제되지는 않지만, 콜백이 다시 호출되지 않음이 보장됩니다. 콜백이 등록 해제되지 않기 때문에 이 메서드는 콜백 자체의 콜백 함수 내에서 안전하게 호출할 수 있습니다. 현재 콜백은 실행을 완료하지만 다시 호출되지 않습니다. 언제든지 콜백은 64개만 허용되므로 결국 콜백은 등록 해제해야 합니다.