This document is about: QUANTUM 2
SWITCH TO

캐싱

유니티 엔진 틱 속도는 시뮬레이션 틱 속도와 다르므로 동기화를 유지할 수 없습니다. 즉, 입력 장치를 통해 수행된 작업을 캐시하고 요청 시 시뮬레이션으로 전송하는 메커니즘이 필요합니다.

이상적인 시나리오

이상적인 시나리오는 입력 장치에서 입력을 폴링 하여 캐시 된 Quantum.Input에 저장하고 Quantum 마지막으로 시뮬레이션이 틱할 때 동일한 유니티 프레임에서 읽습니다. 아래 그림에 나와 있습니다.

fps template input caching in an ideal scenario
이상적인 시나리오에서 FPS 템플릿 입력 캐싱

렌더링은 시뮬레이션보다 더 빠릅니다

일반적으로 렌더링 속도는 시뮬레이션 속도(예: 렌더링 60Hz, 시뮬레이션 30Hz)보다 빠릅니다. 이 경우 시뮬레이션이 틱하지 않고 진행되는 유니티 프레임이 존재합니다. 시뮬레이션 델타 시간이 충분한 시간을 축적하지 못했기 때문에 유니티의 뷰에서 입력을 폴링 하지 않습니다. 그럼에도 불구하고 입력은 입력 장치에서 캐시 되어야 합니다. 그렇지 않으면 중요한 입력 이벤트가 손실되어 플레이어의 예상과 맞지 않는 입력 동작이 발생할 수 있습니다. 이 문제를 해결하기 위해 시뮬레이션에서 아직 폴링 하지 않은 경우 두 유니티 프레임을 위해 입력은 Quantum.Input 구조체에 캐시 됩니다.

fps template input caching when rendering is faster than simulation
렌더링 속도가 시뮬레이션 속도보다 빠를 때의 FPS 템플릿 입력 캐싱

렌더링은 시뮬레이션보다 더 느립니다

렌더링 속도가 시뮬레이션 속도(예: 렌더링 30Hz, 시뮬레이션 60Hz)보다 느릴 가능성은 낮지만 발생 가능한 시나리오입니다. 이 경우 Quantum 시뮬레이션이 여러 틱을 진행하는 동안 일부 유니티 프레임이 발생합니다. 동일한 입력을 여러 번 읽지 않도록 Quantum.Input 데이터 구조체에는 Reset() 메소드가 포함되어 있습니다. Reset()'은 단일 Quantum 틱에 대한 시뮬레이션에서 입력을 폴링 한 후 즉시 실행됩니다. 이러한 상황은 일반적으로 특히 네트워크 지연 또는 렌더링 스파이크가 발생할 때입니다(예: 100ms 스파이크는 다음 유니티 프레임에서 6개의 Quantum 틱을 시뮬레이션합니다).

fps template input caching when rendering is slower than simulation
렌더링 속도가 시뮬레이션 속도보다 느릴 때의 FPS 템플릿 입력 캐싱
Back to top