Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Godot.
Checking the stable version of the documentation...
지터, 끊김 및 입력 지연 수정
지터, 끊김 및 입력 지연이란 무엇입니까?
*지터*와 *스터터*는 최고 속도로 실행하는 경우에도 게임에 영향을 미칠 수 있는 화면상의 개체 움직임에 대한 두 가지 다른 변경 사항입니다. 이러한 효과는 러너나 플랫포머처럼 세계가 고정된 방향으로 일정한 속도로 움직이는 게임에서 주로 볼 수 있습니다.
*입력 지연*은 지터 및 끊김 현상과 관련이 없지만 때때로 함께 논의됩니다. 입력 지연은 마우스, 키보드, 컨트롤러 또는 터치스크린을 사용하여 작업을 수행할 때 눈에 보이는 화면상 지연을 의미합니다. 이는 게임 코드, 엔진 코드 또는 외부 요인(예: 하드웨어)과 관련될 수 있습니다. 입력 지연은 1인칭 게임과 같이 마우스를 사용하여 조준하는 게임에서 가장 두드러집니다. 입력 지연을 완전히 없앨 수는 없지만 여러 가지 방법으로 줄일 수는 있습니다.
지터와 스터터의 구별
아무런 효과도 나타내지 않고 일반 프레임 속도로 실행되는 게임은 부드럽게 보입니다.
*지터*를 나타내는 게임은 매우 미묘한 방식으로 끊임없이 흔들리게 됩니다.
마지막으로 더듬 현상이 나타나는 게임은 매끄럽게 보이지만 몇 초마다 *중지*되거나 *프레임 롤백*되는 것처럼 보입니다.
지터
지터의 원인은 다양할 수 있습니다. 가장 일반적인 현상은 게임 *물리적 주파수*(보통 60Hz)가 모니터 새로 고침 빈도와 다른 해상도에서 실행될 때 발생합니다. 모니터 주사율이 60Hz와 다른지 확인하세요.
때때로 일부 개체(문자 또는 배경)만 흔들리는 것처럼 보입니다. 이는 서로 다른 시간 소스에서 처리될 때 발생합니다(하나는 물리 단계에서 처리되고 다른 하나는 유휴 단계에서 처리됨).
이러한 지터 원인은 프로젝트 설정에서 :ref:`물리 보간 <doc_physics_interpolation_quick_start_guide>`을 활성화하여 완화할 수 있습니다. 물리 보간은 물리 프레임 사이에서 물리 개체의 변환을 보간하여 물리 업데이트를 원활하게 합니다. 이런 식으로 물리 개체의 시각적 표현은 프레임 속도와 물리 틱 속도에 관계없이 항상 부드럽게 보입니다.
물리 보간을 활성화하려면 주의해야 할 몇 가지 주의 사항이 있습니다. 예를 들어 개체를 순간 이동할 때는 의도하지 않은 경우 이전 위치와 새 위치 사이에 눈에 띄게 보간되지 않도록 주의해야 합니다. 자세한 내용은 물리 소개 문서를 참조하세요.
참고
물리 보간을 활성화하면 플레이어 움직임과 같이 물리 틱에 따라 달라지는 동작에 대한 입력 지연이 증가합니다. 대부분의 게임에서 이는 일반적으로 지터보다 선호되지만 고정 프레임 속도에서 작동하는 게임(예: 격투 또는 리듬 게임)에서는 이를 신중하게 고려하십시오. 입력 지연의 이러한 증가는 입력 섹션에 설명된 대로 물리 틱 속도를 증가시켜 보상할 수 있습니다.
말더듬
말더듬은 여러 가지 이유로 발생할 수 있습니다. 한 가지 이유는 CPU 또는 GPU 병목 현상으로 인해 게임이 전체 프레임 속도 성능을 유지할 수 없기 때문입니다. 이 문제를 해결하는 것은 게임마다 다르며 :ref:`optimization <doc_general_optimization>`이 필요합니다.
끊김이 발생하는 또 다른 일반적인 이유는 *셰이더 컴파일 끊김*입니다. 이는 게임에서 처음으로 새로운 재질이나 입자 효과가 생성될 때 셰이더를 컴파일해야 할 때 발생합니다. 이러한 종류의 끊김 현상은 일반적으로 처음 플레이할 때나 그래픽 드라이버 업데이트 후에 셰이더 캐시가 무효화될 때 발생합니다.
Godot 4.4부터 Forward+ 또는 모바일 렌더러를 사용할 때 엔진은 ubershader 접근 방식을 사용하여 셰이더 컴파일 끊김을 방지하려고 합니다. 이 접근 방식이 가장 효과적이려면 장면과 리소스를 디자인할 때 주의를 기울여야 합니다. 그래야 Godot가 처음으로 그릴 때와는 반대로 씬/리소스가 로드될 때 가능한 많은 정보를 수집할 수 있습니다. 자세한 내용은 :ref:`doc_pipeline_compilations`를 참조하세요.
그러나 호환성 렌더러를 사용하는 경우 OpenGL의 기술적 한계로 인해 이 ubershader 접근 방식을 사용할 수 없습니다. 따라서 호환성 렌더러에서 셰이더 컴파일 끊김 현상을 방지하려면 레벨이 로드될 때 단일 프레임에 대해 카메라 앞에 모든 메시와 시각 효과를 생성해야 합니다. 이렇게 하면 게임플레이 중에 발생하는 것이 아니라 레벨이 로드될 때 셰이더가 컴파일됩니다. 이 작업은 플레이어에게 표시되지 않도록 견고한 2D UI(예: 전체 화면 ColorRect 노드) 뒤에서 수행할 수 있습니다.
참고
V-Sync 비활성화를 지원하는 플랫폼에서는 프로젝트 설정에서 V-Sync를 비활성화하여 끊김 현상을 덜 눈에 띄게 만들 수 있습니다. 그러나 이로 인해 특히 새로 고침 빈도가 낮은 모니터에서 찢어짐이 나타날 수 있습니다. 모니터가 이를 지원하는 경우 V-Sync를 활성화한 상태에서 가변 새로 고침 빈도(G-Sync/FreeSync)를 활성화하는 것이 좋습니다. 이를 통해 찢어짐 현상 없이 일부 형태의 말더듬 현상을 완화할 수 있습니다. 그러나 셰이더 컴파일 끊김으로 인한 것과 같은 큰 끊김 현상에는 도움이 되지 않습니다.
그래픽 카드가 최대 성능 프로필을 사용하도록 강제하면 GPU 전력 소모가 증가하는 대신 끊김 현상을 줄이는 데 도움이 될 수도 있습니다.
또한 기본 운영 체제로 인해 끊김 현상이 발생할 수도 있습니다. 다음은 다양한 OS의 끊김 현상에 관한 몇 가지 정보입니다.
Windows
Windows는 창 모드 게임에서 끊김 현상을 일으키는 것으로 알려져 있습니다. 이는 주로 설치된 하드웨어, 드라이버 버전 및 병렬로 실행되는 프로세스에 따라 달라집니다(예: 많은 브라우저 탭을 열어두면 실행 중인 게임이 끊길 수 있습니다). 이를 방지하기 위해 Godot는 게임 우선순위를 "Above Normal"로 높입니다. 이는 상당히 도움이 되지만 말더듬을 완전히 제거할 수는 없습니다.
이 문제를 완전히 제거하려면 게임에 "Time Critical" 상태가 되도록 모든 권한을 부여해야 하는데, 이는 권장되지 않습니다. 일부 게임에서는 이 문제가 발생할 수 있지만 Windows 게임에서는 일반적이고 대부분의 사용자는 창 모드에서 게임을 플레이하지 않으므로 이 문제를 해결하는 방법을 배우는 것이 좋습니다(퍼즐 게임과 같이 창에서 플레이하는 게임은 일반적으로 어쨌든 이 문제가 발생하지 않습니다).
전체 화면의 경우 Windows는 게임에 특별한 우선 순위를 부여하므로 끊김 현상이 더 이상 표시되지 않으며 매우 드뭅니다. 이것이 대부분의 게임이 진행되는 방식입니다.
폴링 속도가 1,000Hz 이상인 마우스를 사용하는 경우 높은 폴링 속도 마우스의 높은 CPU 사용률과 관련된 수정 사항이 포함된 최신 Windows 11 설치를 사용하는 것이 좋습니다. 이러한 수정 사항은 Windows 10 및 이전 버전에서는 사용할 수 없습니다.
Linux
끊김 현상은 데스크톱 Linux에서 나타날 수 있지만 일반적으로 다른 비디오 드라이버 및 합성기와 관련이 있습니다. 일부 합성기는 이 문제(예: KWin)를 유발할 수도 있으므로 원인을 배제하기 위해 다른 합성기를 사용하는 것이 좋습니다. KWin 및 Xfwm과 같은 일부 창 관리자에서는 합성을 수동으로 비활성화하여 성능을 향상시킬 수 있습니다(찢기 대신).
드라이버나 컴포지터 개발자에게 문제로 보고하는 것 외에는 드라이버나 컴포지터 끊김에 대한 해결 방법이 없습니다. 합성이 비활성화된 경우에도 전체 화면이 아닌 창 모드에서 플레이할 때 끊김 현상이 더 많이 나타날 수 있습니다.
`Feral GameMode <https://github.com/FeralInteractive/gamemode>`__을 사용하면 특정 프로세스를 실행할 때 자동으로 최적화(예: GPU 성능 프로필 강제 적용)를 적용할 수 있습니다.
macOS
일반적으로 macOS는 끊김 현상이 없지만 최근 전체 화면에서 실행할 때 일부 버그가 보고되었습니다(이것은 macOS 버그입니다). 이러한 동작을 보이는 기계가 있는 경우 알려주시기 바랍니다.
Android
일반적으로 Android에서는 실행 중인 활동이 모든 우선순위를 갖기 때문에 끊김 현상이 없고 지터 현상이 없습니다. 즉, 문제가 있는 장치가 있을 수 있습니다(이전 Kindle Fire도 그중 하나인 것으로 알려져 있습니다). Android에서 이 문제가 발생하면 알려주시기 바랍니다.
iOS
iOS 장치는 일반적으로 끊김 현상이 없지만 최신 버전의 운영 체제를 실행하는 구형 장치에서는 문제가 발생할 수 있습니다. 이는 일반적으로 불가피합니다.
입력
프로젝트 조직
V-Sync 비활성화를 지원하는 플랫폼에서는 프로젝트 설정에서 V-Sync를 비활성화하여 입력 지연을 덜 눈에 띄게 만들 수 있습니다. 그러나 이로 인해 특히 새로 고침 빈도가 낮은 모니터에서 찢어짐이 나타날 수 있습니다. 플레이어가 전환할 수 있는 옵션으로 V-Sync를 제공하는 것이 좋습니다.
Forward+ 또는 모바일 렌더링 방법을 사용할 때 V-Sync가 활성화되었을 때 시각적 대기 시간을 줄이는 또 다른 방법은 기본 삼중 버퍼 V-Sync 대신 이중 버퍼 V-Sync를 사용하는 것입니다. Godot 4.3부터 디스플레이 > 창 > V-Sync > Swapchain Image Count 프로젝트 설정을 ``2``로 줄여 이를 달성할 수 있습니다. 이중 버퍼링 사용의 단점은 CPU 또는 GPU 병목 현상으로 인해 디스플레이 새로 고침 빈도에 도달할 수 없는 경우 프레임 속도가 덜 안정적이라는 것입니다. 예를 들어, 60Hz 디스플레이에서 삼중 버퍼링을 사용하여 게임 플레이 중에 프레임 속도가 일반적으로 55FPS로 떨어지면 이중 버퍼링을 사용하여 일시적으로 30FPS로 낮아져야 합니다(그런 다음 가능하면 60FPS로 돌아갑니다). 결과적으로 이중 버퍼 V-Sync는 대상 하드웨어에서 디스플레이 새로 고침 빈도에 일관적으로 도달할 수 있는 경우에만 권장됩니다.
초당 물리 반복 횟수를 늘리면 물리로 인한 입력 대기 시간도 줄일 수 있습니다. 이는 물리 보간(부드러움은 향상되지만 대기 시간은 증가함)을 사용할 때 특히 두드러집니다. 이렇게 하려면 **Physics > Common > Physics Ticks Per Second**를 기본 60``보다 높은 값으로 설정하거나 런타임 시 스크립트에서 ``Engine.physics_ticks_per_second``를 설정하세요. 모니터 새로 고침 빈도(일반적으로 ``60)의 배수인 값은 지터를 방지하므로 물리 보간이 비활성화된 경우 가장 잘 작동합니다. 이는 120, 180 및 ``240``와 같은 값이 좋은 시작점임을 의미합니다. 보너스로, 물리 FPS가 높을수록 터널링 및 물리 불안정 문제가 발생할 가능성이 줄어듭니다.
물리 FPS를 높이면 CPU 사용량이 늘어나서 물리 시뮬레이션 코드가 많은 게임에서 성능 병목 현상이 발생할 수 있다는 단점이 있습니다. 이는 낮은 대기 시간이 중요한 상황에서만 물리 FPS를 높이거나 플레이어가 하드웨어에 맞게 물리 FPS를 조정하도록 함으로써 완화될 수 있습니다. 그러나 게임 로직에서 ``delta``가 일관되게 사용되는 경우에도 물리 FPS가 다르면 물리 시뮬레이션에서 다른 결과가 발생합니다. 이는 특정 플레이어에게 다른 플레이어보다 이점을 줄 수 있습니다. 따라서 경쟁적인 멀티플레이어 게임에서는 플레이어가 물리 FPS 자체를 변경하도록 허용하는 것을 피해야 합니다.
마지막으로 스크립트에서 Input.set_use_accumulated_input(false)``를 호출하여 렌더링된 프레임별로 입력 버퍼링을 비활성화할 수 있습니다. 이렇게 하면 입력을 누적하고 프레임이 렌더링될 때까지 기다리는 대신 스크립트의 ``_input() 및 _unhandled_input() 함수가 모든 입력에서 호출됩니다. 입력 누적을 비활성화하면 CPU 사용량이 증가하므로 주의해서 수행해야 합니다.
팁
모든 Godot 프로젝트에서 --disable-vsync 명령줄 인수 <doc_command_line_tutorial>`을 사용하여 V-Sync를 강제로 비활성화할 수 있습니다. Godot 4.2부터 `--max-fps <fps>``를 사용하여 FPS 제한을 설정할 수도 있습니다(``0``는 무제한입니다). 이러한 인수는 동시에 사용될 수 있습니다.
Hardware/OS-specific
모니터가 이를 지원하는 경우 V-Sync를 활성화한 상태에서 가변 새로 고침 빈도(G-Sync/FreeSync)를 활성화하는 것을 고려한 다음 `이 페이지 <https://blurbusters.com/howto-low-lag-vsync-on/>`__에 따라 프로젝트 설정에서 프레임 속도를 모니터의 최대 새로 고침 빈도보다 약간 낮은 값으로 제한하십시오. 예를 들어 144Hz 모니터에서는 프로젝트의 프레임 속도 한도를 ``141``로 설정할 수 있습니다. 처음에는 직관적이지 않을 수 있지만 FPS를 최대 새로 고침 빈도 범위 아래로 제한하면 OS가 수직 귀선소거가 완료될 때까지 기다릴 필요가 없습니다. 이로 인해 동일한 프레임 속도 제한(보통 1ms 미만)으로 V-Sync가 비활성화된 것과 비슷한 입력 지연이 발생하지만 테어링은 발생하지 않습니다.
이는 애플리케이션 > 실행 > 최대 FPS 프로젝트 설정을 변경하거나 스크립트에서 런타임에 ``Engine.max_fps``를 할당하여 수행할 수 있습니다.
일부 플랫폼에서는 그래픽 드라이버 옵션(예: Windows의 NVIDIA 제어판)에서 저지연 모드를 선택할 수도 있습니다. Ultra 설정은 평균 프레임 속도를 약간 낮추는 대신 가능한 가장 낮은 지연 시간을 제공합니다. GPU가 최대 성능 프로필을 사용하도록 강제하면 전력 소비가 높아지는 대신 입력 지연이 더욱 줄어들 수 있습니다(그리고 그에 따른 열/팬 소음).
마지막으로, 모니터가 OS의 디스플레이 설정에서 가능한 가장 높은 새로 고침 빈도로 실행되고 있는지 확인하세요.
또한 마우스가 가장 높은 폴링 속도(게임용 마우스의 경우 일반적으로 1,000Hz, 때로는 그 이상)를 사용하도록 구성되어 있는지 확인하십시오. 그러나 USB 폴링 속도가 높으면 CPU 사용량이 높아질 수 있으므로 저가형 CPU에서는 500Hz가 더 안전한 선택일 수 있습니다. 마우스가 여러 DPI 설정을 제공하는 경우 가능한 가장 높은 설정을 사용하고 게임 내 민감도를 줄여 마우스 대기 시간을 줄이는 것도 고려해 보세요.
Linux에서 X11을 사용할 때 이를 허용하는 창 관리자(예: KWin 또는 Xfwm)에서 합성을 비활성화하면 입력 지연을 크게 줄일 수 있습니다.
지터, 끊김 또는 입력 지연 문제 보고
위의 원인으로 인해 발생하지 않은 끊김 또는 지터 문제(문제 발생)를 보고하는 경우 장치, 운영 체제, 드라이버 버전 등에 대해 가능한 모든 정보를 매우 명확하게 지정하십시오. 이는 문제를 해결하는 데 도움이 될 수 있습니다.
입력 지연 문제를 신고하는 경우 고속 카메라로 촬영한 캡처(예: 휴대폰의 슬로우 모션 비디오 모드)를 포함해 주세요. 입력과 화면 결과 사이의 프레임 수를 계산할 수 있도록 캡처 반드시 화면과 입력 장치가 모두 표시되어야 합니다. 또한 모니터의 새로 고침 빈도와 입력 장치의 폴링 빈도(특히 마우스의 경우)를 언급하세요.
또한 표시된 동작에 따라 올바른 용어(지터, 끊김, 입력 지연)를 사용해야 합니다. 이렇게 하면 문제를 훨씬 더 빨리 이해하는 데 도움이 됩니다. 문제를 재현하는 데 사용할 수 있는 프로젝트를 제공하고, 가능하다면 버그를 보여주는 화면 캡처를 포함하세요.