예컨대 , 게임 그래픽 은 일반 적 으로 프레임 마다 계산 된다 . 많 은 게임 에서 , 게임 로직 은 때때로 한 장면 이 특히 복잡 한지 , 또는 만약 슬로우 다운 실행 ( 예컨대 , PC 에서 다른 처리 가 게임 어플리케이션 으로부터 CPU 사이클 을 가져가 도록 실행 될 것 이 다 ) 과 같 은 그 밖 의 지연 이 있 는지 에 따라 , 다음 프레임 을 디스플레이 하 기 위한 그래픽 을 연산 하 기 위해 한 프레임 시간 보다 짧 거나 길 게 걸릴 수 있 을 것 이 다 . 그러 한 게임 에서 , 한 프레임 시간 ( 소위 , " CPU 클럭 사이클 보다 적음 ) 보다 훨씬 적 은 시간 에 연산 되 는 "" 문턱 ( threshold ) "" 프레임 이 결국 일어날 수 있 다 . 동일 한 장면 은 정확히 동일 한 게임 상태 정보 를 사용 하 여 다시 연산 될 때 ", 한 프레임 시간 ( 예컨대 , 만약 내부 CPU 버스 가 외부 DRAM 버스 와 조금 위상 이 벗어나 고 ( out of phase ) 그것 이 CPU 사이클 시간 의 지연 을 유도 한다면 , 그럼에도 불구 하 고 게임 처리 에서 CPU 시간 의 수 밀리 세컨드 ( millisecond ) 가 걸리 는 다른 처리 에서 큰 지연 이 있 지 않 다 ) 보다 적 은 CPU 클럭 사이클 이 걸릴 수 있 다 . 따라서 , 게임 이 플레이 백 ( play back ) 된 때 , 프레임 은 단일 프레임 시간 보다 2 개 프레임 시간 으로 연산 되 어 얻 어 진다 . 어떤 동작 은 게임 이 얼마나 자주 새로운 프레임 ( 예컨대 , 게임 이 게임 컨트롤러 로부터 입력 을 샘플 할 때 ) 을 연산 하 는지 에 기초 한다 . 게임 이 재생 되 는 동안 , 다른 동작 을 위한 시간 기준 에서 이러 한 차이 는 게임 플레이 에 영향 을 주 지 않 지만 , 그것 은 플레이 백 게임 에서 다른 결과 를 생산 하 는 결과 를 초래 할 수 있 다 . 예컨대 , 만약 농구공 의 탄도 는 안정 적 으로 60 fps 속도 로 연산 되 지만 , 게임 컨트롤러 입력 은 연산 된 프레임 의 속도 에 기초 하 여 샘플 되 고 , 게임 이 기록 된 때 에 연산 된 프레임 의 속도 는 53 fps 일 것 이 지만 게임 이 리플레 이 될 때 는 52 fps 이 므로 , 이 는 농구공 이 바스켓 으로 들어가 는 것 이 차단 되 는지 또는 아닌지 사이 에 차이 를 만들 수 있 어 , 다른 결과 를 초래 한다 . 따라서 , 비디오 게임 을 기록 하 기 위해 게임 상태 를 사용 하 는 것 은 정확히 동일 한 결과 를 생산 하 는 동일 한 게임 상태 정보 를 사용 하 고 , 리플레이 를 보장 하 기 위해 매우 신중 한 게임 소프트웨어 디자인 이 요구 된다 .