게임 루프에서 업데이트 독립 렌더링의 요점은 무엇입니까?

게임 루프에 관한 수십 개의 기사, 서적 및 토론이 있습니다. 그러나 나는 종종 다음과 같은 것을 보게됩니다.

while(running)
{
    processInput();
    while(isTimeForUpdate)
    {
        update();
    }
    render();
}

기본적으로이 접근 방식에 대해 귀찮은 것은 "업데이트 독립적"렌더링입니다. 예를 들어 변경이 없을 때 프레임을 렌더링합니다. 그래서 제 질문은 왜이 접근법이 종종 가르쳐 지는가?

우리가 길을 따라 많은 흥미 진진한 도전과 함께, 우리가이 공동의 대회에 어떻게 도착했는지에 대한 오랜 역사가 있습니다.

1. 문제 : 장치가 다른 속도로 작동

현대의 PC에서 오래된 DOS 게임을 시도해 보았는데, 그것은 흐릿하게 실행될 수 있습니까?

많은 오래된 게임에는 매우 순진한 업데이트 루프가있었습니다. 입력 시간을 수집하고 게임 상태를 업데이트하며 시간이 얼마나 걸리는지 계산하지 않고 하드웨어가 허용하는 한 빨리 렌더링합니다. 즉, 하드웨어가 변경되는 즉시 게임 플레이가 변경됩니다.

우리는 일반적으로 플레이어가 작년의 전화를 사용하든 최신 모델을 사용하든, 최고급 게임용 데스크톱 또는 중간 계층 노트북.

특히 (멀티 플레이어 또는 리더 보드를 통해) 경쟁이 치열한 게임의 경우 특정 장치에서 실행중인 플레이어가 더 빨리 실행하거나 반응 시간이 더 길어질 수 있기 때문에 다른 장치보다 이점을 갖기를 원하지 않습니다.

확실한 해결책은 게임 플레이 상태 업데이트 속도를 고정시키는 것입니다. 그렇게하면 결과가 항상 동일하다는 것을 보장 할 수 있습니다.

2. 그렇다면 왜 프레임 속도를 잠그고 (예 : VSync 사용) 여전히 잠금 단계에서 게임 플레이 상태 업데이트 및 렌더링을 실행하지 않습니까?

이것은 효과가 있지만 항상 청중에게 만족스러운 것은 아닙니다. 30fps의 고체로 게임을하는 데 오랜 시간이 걸렸습니다. 이제 플레이어는 일반적으로 최소 60fps를 최소 막대로, 특히 멀티 플레이어 액션 게임에서 기대하고 있으며, 일부 오래된 타이틀은 기대치가 바뀌면서 눈에 띄게 고르지 않게 보입니다. 특히 잠금 장치의 프레임 속도를 반대하는 PC 플레이어 그룹이 있습니다. 그들은 최첨단 하드웨어에 많은 비용을 지불했으며, 컴퓨팅 근육을 최대한 부드럽고 충실도 높은 렌더링에 사용할 수 있기를 원했습니다.

특히 VR에서는 프레임 속도가 최고이며 표준은 계속해서 올라갑니다. 최근 VR의 부활 초기에 게임은 종종 약 60fps로 실행되었습니다. 이제 90이 표준이되었으며 PSVR과 같은 하드웨어가 120을 지원하기 시작했습니다. 이는 계속 증가 할 수 있습니다. 따라서 VR 게임의 프레임 속도가 현재 수행 가능한 작업으로 제한되는 경우 하드웨어 및 기대치가 계속 발전함에 따라 뒤쳐 질 수 있습니다.

일반적으로 프레임을 순서대로 인식하는 것과 같이 특정 유형의 "인식"을 기반으로하기 때문에 "플레이어는 XXX보다 빠른 것을 인식 할 수 없다"는 말에주의해야합니다. 모션의 연속성 인식은 일반적으로 훨씬 더 민감한.)

마지막 문제는 고정 프레임 속도를 사용하는 게임도 보수적이어야한다는 것입니다. 게임에서 비정상적으로 많은 수의 객체를 업데이트하고 표시하는 순간을 맞이한 경우 프레임을 놓치고 싶지 않습니다. 마감일과 눈에 띄는 말더듬 또는 장애를 일으 킵니다. 따라서 헤드 룸을 떠나기 위해 콘텐츠 예산을 충분히 낮게 설정하거나 전체 사양을 최소 사양의 하드웨어에서 최악의 성능으로 유지하는 것을 피하기 위해보다 복잡한 동적 품질 조정 기능에 투자해야합니다.

성능 문제가 개발 후반에 나타나는 경우, 기존의 모든 시스템이 이제는 항상 도달 할 수없는 잠금 단계 렌더링 프레임 속도를 가정하여 빌드 및 조정될 때 특히 문제가 될 수 있습니다. 업데이트 및 렌더링 속도를 분리하면 성능 변동을 처리 할 수있는 유연성이 향상됩니다.

3. 정해진 시간 간격으로 업데이트 할 때 (2)와 동일한 문제가 없습니까?

이것이 원래 질문의 핵심이라고 생각합니다. 업데이트를 분리하고 때로는 게임 상태 업데이트가없는 두 프레임을 렌더링하는 경우 눈에 띄는 변화가 없으므로 낮은 프레임 속도에서 잠금 단계 렌더링과 동일하지 않습니다. 화면?

실제로 게임에서 이러한 업데이트의 디커플링을 사용하는 방법에는 여러 가지가 있습니다.

a) 업데이트 속도는 렌더링 된 프레임 속도 보다 빠를 수 있습니다.

tyjkenn이 다른 답변에서 언급했듯이 물리학은 특히 렌더링보다 더 높은 빈도로 강화되므로 통합 오류를 최소화하고보다 정확한 충돌을 제공합니다. 따라서 렌더링 된 프레임간에 0 또는 1 개의 업데이트가 아닌 5 또는 10 또는 50이있을 수 있습니다.

이제 120fps로 렌더링하는 플레이어는 프레임 당 2 개의 업데이트를 얻을 수 있으며, 30fps로 사양이 낮은 하드웨어 렌더링을 사용하는 플레이어는 프레임 당 8 개의 업데이트를 받고 두 게임 모두 동일한 초당 게임 속도로 실행됩니다. 더 좋은 하드웨어는 더 매끄럽게 보이지만 게임 플레이의 작동 방식을 근본적으로 바꾸지는 않습니다.

업데이트 속도가 프레임 속도와 일치하지 않으면 둘 사이의 "비트 주파수"를 얻을 수 있는 위험 이 있습니다 . 예 : 대부분의 프레임은 4 개의 게임 상태 업데이트를위한 충분한 시간과 약간의 남은 시간을가집니다. 그런 다음 매번 프레임에서 5 개의 업데이트를 수행하기 위해 충분히 절약하여 움직임에 약간의 점프 또는 말더듬을 만듭니다. 이것은 다음과 같이 해결할 수 있습니다 ...

b) 업데이트 사이의 게임 상태 보간 (또는 외삽)

여기서 우리는 종종 게임 상태를 미래에 정해진 시간 간격으로 유지하고, 가장 최근의 두 상태에서 충분한 정보를 저장하여 그들 사이에 임의의 지점을 만들 수 있습니다. 그런 다음 화면에 새 프레임을 표시 할 준비가되면 표시 목적으로 만 적절한 순간에 혼합됩니다 (즉, 여기서 기본 게임 플레이 상태를 수정하지 않음)

올바르게 수행하면 움직임이 버터처럼 부드럽게 느껴지고 너무 낮아 지지 않는 한 프레임 속도의 일부 변동을 가리는 데 도움이됩니다 .

c) 비 게임 플레이 상태 변경에 평활도 추가

게임 플레이 상태를 보간하지 않더라도 약간의 평활도를 얻을 수 있습니다.

캐릭터 애니메이션, 파티클 시스템 또는 VFX와 같은 시각적 변화와 HUD와 같은 사용자 인터페이스 요소는 종종 게임 플레이 상태의 고정 된 시간 간격과 별도로 업데이트됩니다. 즉, 프레임 당 게임 플레이 상태를 여러 번 똑딱 거리면 모든 틱마다 비용을 지불하지 않고 최종 렌더링 패스에서만 지불합니다. 대신, 우리는 이러한 효과의 재생 속도를 프레임 길이에 맞게 조정하므로 렌더링 속도가 허용하는 한도 내에서 (1)에 설명 된대로 게임 속도 나 공정성에 영향을주지 않고 부드럽게 재생합니다.

카메라 움직임도이 작업을 수행 할 수 있습니다. 특히 VR에서는 때때로 같은 프레임을 두 번 이상 표시하지만 그 사이에있는 플레이어의 머리 움직임을 고려하여 프레임을 다시 투영 하여인지 할 수있는 대기 시간과 편안함을 향상시킬 수 있습니다. 기본적으로 모든 것을 그렇게 빨리 렌더링하지는 않습니다. 일부 게임 스트리밍 시스템 (게임이 서버에서 실행되고 플레이어가 씬 클라이언트 만 실행하는 경우)도이 버전을 사용합니다.

4. 왜 모든 것에 그 (c) 스타일을 사용하지 않습니까? 애니메이션 및 UI에서 작동하는 경우 현재 프레임 속도에 맞게 게임 플레이 상태 업데이트를 간단하게 조정할 수 없습니까?

예 * 가능하지만 간단하지 않습니다.

이 답변은 이미 약간 길기 때문에 모든 세부 사항을 다루지 않고 간단한 요약 만 할 것입니다.

• 곱한 deltaTime작동하는 가변 길이의 갱신을 조정하는 선형 변화 (애니메이션 타임 라인을 따라 예. 등속 운동, 타이머의 카운트 다운 또는 진행)

• 불행히도 게임의 많은 측면이 비선형 적 입니다. 중력만큼 단순한 것조차도 다양한 프레임 속도에서 결과가 다른 것을 피하기 위해 더 복잡한 통합 기술 또는 고해상도 하위 단계가 필요합니다. 플레이어 입력 및 제어 자체는 비선형 성의 큰 원천입니다.

• 특히, 이산 충돌 감지 및 해상도의 결과는 업데이트 속도에 따라 달라지며 프레임이 너무 길면 터널링 및 지 터링 오류가 발생합니다. 따라서 다양한 프레임 속도로 인해 더 많은 컨텐츠에 대해 더 복잡하고 비싼 연속 충돌 감지 방법을 사용하거나 물리학의 가변성을 허용해야합니다. 연속 충돌 감지조차도 물체가 호에서 움직일 때 문제가 발생하여 더 짧은 시간 간격이 필요합니다 ...

따라서 중간 정도의 복잡성 게임의 경우 일반적으로 deltaTime스케일링을 통해 일관된 행동 및 공정성을 유지하는 것은 매우 어렵고 유지 관리에 중점을 두어 완전히 불가능한 것입니다.

업데이트 속도를 표준화하면 종종 간단한 코드 로 다양한 조건 에서 보다 일관된 동작을 보장 할 수 있습니다 .

이 업데이트 속도 유지 렌더링에서 분리하는 것은 우리에게주는 유연성 경험의 부드러움과 성능을 제어하는 게임 플레이 로직을 변경하지 않고를 .

그럼에도 불구하고 우리는 진정으로 "완벽한"프레임 속도 독립성을 얻지 못하지만 게임의 많은 접근 방식과 마찬가지로 주어진 게임의 요구에 대해 "충분히 좋은"쪽으로 전화를 걸 수있는 제어 가능한 방법을 제공합니다. 이것이 유용한 출발점으로 일반적으로 가르치는 이유입니다.

다른 대답은 좋으며 게임 루프가 존재하는 이유와 렌더링 루프와 분리되어야하는 이유에 대해 이야기합니다. 그러나 "변경 사항이 없는데 왜 프레임을 렌더링해야합니까?"의 구체적인 예는? 그것은 실제로 하드웨어와 복잡성에 달려 있습니다.

비디오 카드는 상태 머신이며 동일한 작업을 계속 반복해서 잘 수행합니다. 변경 한 것만 렌더링하면 실제로 더 비싸지 않습니다. 대부분의 시나리오에는 정적 요소가 많지 않습니다. FPS 게임에서 약간 왼쪽으로 이동하면 화면에서 물건의 98 % 픽셀 데이터를 변경하면 전체 프레임을 렌더링 할 수도 있습니다.

그러나 주로 복잡성. 모든 것을 재 작업하거나 일부 알고리즘의 이전 결과를 추적하고 새로운 결과와 비교하고 변경이 다른 경우에만 픽셀을 렌더링해야하기 때문에 업데이트하는 동안 변경된 모든 것을 추적하는 것은 훨씬 더 비쌉니다. 시스템에 따라 다릅니다.

하드웨어 등의 디자인은 현재 컨벤션에 크게 최적화되어 있으며 상태 머신은 시작하기에 좋은 모델입니다.

렌더링은 일반적으로 게임 루프에서 가장 느린 프로세스입니다. 사람은 60보다 빠른 프레임 속도의 차이를 쉽게 인식하지 못하기 때문에 렌더링보다 더 빨리 렌더링하는 데 시간을 낭비하는 것이 덜 중요합니다. 그러나 더 빠른 속도로 더 많은 혜택을 얻을 수있는 다른 프로세스가 있습니다. 물리학은 하나입니다. 하나의 루프에서 너무 큰 변화는 객체가 벽을 지나서 바로 글리치 할 수 있습니다. 더 큰 증분으로 간단한 충돌 오류를 해결할 수있는 방법이있을 수 있지만 복잡한 물리 상호 작용이 많을 경우 동일한 정확도를 얻지 못할 수 있습니다. 물리 루프가 더 자주 실행되는 경우 매번 렌더링되지 않고 객체를 더 작은 단위로 이동할 수 있기 때문에 글리치가 발생할 가능성이 줄어 듭니다. 민감한 물리 엔진에 더 많은 리소스가 사용되며 사용자가 볼 수없는 더 많은 프레임을 그리는 데 더 적은 리소스가 사용됩니다.

이것은 그래픽을 많이 사용하는 게임에서 특히 중요합니다. 모든 게임 루프에 대해 하나의 렌더가 있고 플레이어에 가장 강력한 머신이없는 경우 게임에서 fps가 30 또는 40으로 떨어지는 지점이있을 수 있습니다. 여전히 끔찍한 프레임 속도는 아니지만 글리치를 피하기 위해 각 물리 변화를 합리적으로 작게 유지하려고하면 게임 속도가 상당히 느려지기 시작합니다. 플레이어는 자신의 캐릭터가 정상 속도의 절반 만 걷는다는 사실에 짜증이납니다. 그러나 렌더링 속도가 나머지 루프와 무관 한 경우 플레이어는 프레임 속도의 감소에도 불구하고 고정 된 보행 속도를 유지할 수 있습니다.

렌더링 하위 시스템에 "마지막 렌더링 이후의 경과 시간" 이라는 개념이 있다면 질문의 구성과 같은 구성이 의미가 있습니다 .

예를 들어, 게임 세계에서 객체의 위치가 (x,y,z)현재 좌표 벡터를 추가로 저장하는 접근 방식으로 고정 좌표를 통해 표현 되는 접근 방식을 고려하십시오 (dx,dy,dz). 이제 메소드 에서 위치 변경이 발생 하도록 게임 루프를 작성할 수 update있지만, 이동 중에 변경이 발생 하도록 설계 할 수도 있습니다 update. 게임 상태는 실제로 다음 때까지 변경되지 않습니다 비록 후자의 접근 방식과 함께 update하는render더 높은 빈도로 호출되는 함수는 이미 약간 업데이트 된 위치에 오브젝트를 그릴 수 있습니다. 이것이 기술적으로 보이는 것과 내부적으로 표현 된 것 사이에 불일치가 발생하지만, 그 차이는 대부분의 실제적인 측면에는 중요하지 않지만 애니메이션은 훨씬 매끄럽게 보입니다.

예를 들어 네트워크 입력 대기 시간을 고려할 때 게임 상태의 "미래"를 예측하는 것은 (잘못 될 위험이 있음에도 불구하고) 좋은 ​​아이디어가 될 수 있습니다.

다른 답변 외에도 ...

상태 변경을 확인하려면 상당한 처리가 필요합니다. 실제로 처리하는 것과 비교하여 변경 사항을 확인하는 데 비슷한 (또는 그 이상!) 처리 시간이 걸리는 경우 실제로 상황을 개선하지 못한 것입니다. @Waddles 말한대로 이미지를 렌더링의 경우, 비디오 카드는 정말 또 다시 같은 바보 같은 일을 잘, 그것은 단순히 그것을 통해 전송하는 것보다 변화에 대한 데이터의 각 청크를 확인하기 위해 더 많은 비용입니다 처리를 위해 비디오 카드에. 또한 렌더링이 게임 플레이 인 경우 화면 이 마지막 틱에서 변경 되지 않았을 가능성이 거의 없습니다 .

또한 렌더링에 프로세서 시간이 많이 걸린다고 가정합니다. 프로세서와 그래픽 카드에 따라 다릅니다. 수년 동안, 점점 더 정교한 렌더링 작업을 그래픽 카드로 오프로드하고 프로세서에서 필요한 렌더링 입력을 줄이는 데 중점을 두었습니다. 프로세서 render()호출은 단순히 DMA 전송을 설정하는 것이 이상적 입니다. 그런 다음 그래픽 카드에 데이터를 가져 오는 것이 메모리 컨트롤러에 위임되고 이미지 생성이 그래픽 카드에 위임됩니다. 프로세서 를 병렬로 사용 하면서 자체 시간에 할 수 있습니다.물리, 게임 플레이 엔진 및 프로세서가 더 잘하는 다른 모든 것들을 처리합니다. 분명히 현실은 그것보다 훨씬 더 복잡하지만 시스템의 다른 부분으로 작업을 오프로드 할 수있는 것도 중요한 요소입니다.