UPS 및 FPS-무엇을 제한해야하며 왜 그런가요?

현재 C ++ 및 SDL2를 사용하여 게임을 작성 중이며 궁금한 점이 있습니다. 초당 프레임 (FPS) 및 / 또는 초당 업데이트 (UPS)를 제한하는 것이 합리적입니까?

UPS를 제한하면 기본적으로 게임 속도를 제어한다는 생각이 들었습니다. 플레이어가 업데이트 당 1px 씩 이동하고 항상 초당 30 번 업데이트하면 30px / s의 속도로 움직입니다. 초당 계산량이 줄어들 기 때문에 아마도 CPU를 줄일 것입니다. FPS를 제한하면 초당 드로우 콜 수가 감소하므로 GPU를 완화합니다. 나는 그것이 아니라면, 그 모든 것을 올바르게 이해했으면 좋겠다.

내 질문은-내 게임에서 무엇을 제한해야합니까? FPS? UPS? 양자 모두? 둘 다요? 이것에 대한 또 다른 더 나은 접근 방법이 있습니까? 이것은 대부분의 게임에서 어떻게 이루어지며 왜 그런가?

답변은 대단히 감사합니다!

game-loop logic sdl2

— DocCoock
소스

실제로 답은 아니지만 gafferongames.com/game-physics/fix-your-timestep

— Cypher

답변:

그렇습니다.

당신이 말했듯이, 그것은 시스템에 대한 부하를 줄이며 열 및 기타 응용 분야에 좋습니다.

그러나 .... 게임 로직은 초당 업데이트에 의존해서는 안됩니다. 따라서 델타 타임을 살펴 보는 것이 좋습니다. 이렇게하면 게임이 초당 업데이트와 무관하게됩니다.

이 질문을 살펴 보는 것이 좋습니다. 그것을 계산하고 사용하는 방법을 잘 설명합니다. 델타 시간을 얻는 방법

그것이 도움이 되었기를 바랍니다!

— 카레즈
소스

그렇다면 둘 중 하나만 제한해야합니까?

— DocCoock

둘 다 설정에 옵션을 추가하여 조정할 수 있습니다.

— KaareZ

주의 사항 : 물리 엔진을 사용하는 경우 델타 시간 / 가변 업데이트 프레임은 거의 지원 되지 않으므로 의존 하지 마십시오 . 고정 프레임 방식이 필요합니다. 프레임이 많이 변동하는 경우 소프트웨어에 문제가 있음을 의미하며 왜 이런 일이 발생하는지 궁금 할 것입니다. 이러한 경우 DT 접근 방식을 사용하여 다시 고려할 수 있습니다.

— Vaillancourt

델타 시간을 기준으로 업데이트를 사용하여 물리 불안정하고있는 버그로 이어질 수 있습니다 매우 재현하기 어렵다. 일부 게임에서는 특정 프레임 속도에서만 가능한 트릭이 있습니다. 이것이 물리가 종종 고정 프레임 속도로 실행되는 이유입니다. 항상 낮은 업데이트 속도로 보간 할 수 있지만 시뮬레이션이 불안정하면 도움이되지 않습니다.

— Dietrich Epp 2016 년

솔직히 델타 타임은 좋은 생각이 아니라고 생각합니다. 나는 그것을 수년간 사용해 왔으며 두 가지 주요 문제가 있습니다. 다양한 멀티 플레이어 기사를 위해 고정 된 시간 간격을 사용하는 것이 좋습니다. 델타 타임이 너무 길면이를 고려하지 않는 한 벽이나 유사한 버그를 통해 순간 이동할 수 있습니다.

— Programmdude

가장 좋은 대답은 : 그것은 의존한다 .

어느 쪽도 제한하지 않아도됩니다

업데이트 : 업데이트가 상한에 묶이지 않으면 게임 논리는 델타 시간 에 의존해야 합니다. 이것은 많은 게임에서 사용되는 매우 일반적인 접근 방법이지만 유일한 방법은 아닙니다.

렌더링 : 렌더링이 상한에 구속되지 않으면 프레임 버퍼가 불완전하거나 잘못된 상태로 표시되어 아티팩트 가 찢어 질 수 있습니다. 많은 게임에서 수직 동기화 (v-sync)를 사용하는 이유

둘 다 제한 할 수 있습니다

업데이트 : 일부 게임 은 일부 또는 모든 게임 플레이 시스템 에 고정 된 시간 간격 을 사용 합니다. 이 방법은 설명한대로 작동합니다. 초당 업데이트 수는 최고 수준의 시스템에서 너무 빨리 움직이지 않도록 상한으로 제한됩니다. 이것은 델타 타이밍의 필요성을 제거합니다. 일부 애플리케이션은 고정 된 타임 스텝으로 개선되고 일부는 델타 타이밍으로 개선됩니다. 어떤 접근 방식을 선택하는지는 정확히 달성하려는 것에 전적으로 달려 있습니다. 온라인 서적 GameProgrammingPatterns 에는 두 아키텍처 모두 를 다루는 게임 루프 전용 장이 있습니다 .

렌더링 : 앞에서 언급 한 테어 링 문제를 피하려면 초당 프레임 수를 상한으로 설정해야하지만 응용 프로그램 은 일부 CPU 잠금으로 수동으로 시도하지 않아야합니다 . 대신 v-sync를 활성화하고 기본 하드웨어가 모니터의 새로 고침 빈도와 동기화되도록하십시오. 이를 통해 게임은 현재 일반적인 60Hz보다 훨씬 높은 주파수에서 작동 할 수있는 미래의 모니터와 호환됩니다. 또한 많은 게이머, 특히 벤치마킹을하는 게이머는 가능한 한 가장 높은 프레임 속도를 허용하기 위해 v-sync없이 실행하는 것을 선호합니다. 따라서 런타임 중에 기능을 활성화하거나 비활성화하는 것이 합리적입니다.

제한해서는 안되는 것

게임에서 사용자 입력에 대한 폴링 기반 접근 방식을 사용하는 경우 (예 : getInput()업데이트 단계에서 컨트롤러 상태를 업데이트하기 위해 일종의 호출) 제한이없는 경우 더 좋습니다. 또는 제한된 경우 매우 높은 상한으로 설정하십시오. 사용자가 입력 한 내용을 자주 쿼리하고 그에 따라 행동할수록 게임의 반응이 빠르고 원활 해집니다. 오늘날 우리가 듣는 소위 60Hz 게임은 AI와 모든 세계 상태를 그 속도로 업데이트하지 않고 일부는 그렇게 빨리 렌더링하지 않지만 컨트롤러 입력을 초당 적어도 60 번 쿼리하고 이에 따라 플레이어 아바타를 업데이트합니다. 이것은 빠른 진행형 액션 게임과 만 관련이 있음을 인정했습니다.

— 글램 퍼트
소스

그래도 VSync가 활성화되면 업데이트도 자동으로 제한됩니다. 따라서 찢어짐 문제와 업데이트 폴링 문제 중 하나를 결정해야합니다.

— DocCoock 2016 년

@DocCoock, 렌더러와 게임 로직이 동일한 스레드에서 실행되는 경우 v-sync를 활성화하면 업데이트 빈도도 수정됩니다. 이것이 일부 게임이 렌더링과 게임 로직을 다른 스레드로 분리하는 이유 중 하나입니다.

— glampert

살펴보고 싶은 두 가지 게시물이 있습니다.

당신의 타임 스텝을 고치세요

보간 물리 렌더링

게시물에 대한 토론은 정말 귀중한 것이지만, 내 생각에 게임에 물리 시뮬레이션이 중요 할 때 가장 의미가 있습니다. 요약하면, 시뮬레이션은 고정 된 시간 단계를 가져야하며 (그렇지 않으면 델타가 너무 큰 지점에서 물리가 폭발 할 수 있음) 렌더링은 가능한 최대 속도로 자유롭게 실행할 수 있어야합니다. 시뮬레이션과 렌더링을 모두 동기화하기 위해 렌더링 상태는 시뮬레이션이 다음 업데이트에서 얼마나 멀리 떨어져 있는지에 따라 결정됩니다 (시뮬레이션이 고정되어 있음을 기억하십시오).

도움이 되길 바랍니다.

— 프랜시스 모이
소스