Latency regression in v2.0-77

[Soreepeong]

Current Behavior

From v2.0-77, Sonic Boom: Rise of Lyric is late to respond to jump command.

Expected Behavior

In v2.0-75 and before, the game responds immediately to jump command.

Steps to Reproduce

Use 84cad8b or any commit after that, and use Graphic Pack "Uncapped Framerate" with 60fps option.

Reverting that commit in particular from the latest commit (v2.0-86) will make the problem disappear.

System Info (Optional)

OS: Windows 11 22631.3737
GPU: RTX 2070 Super

Emulation Settings (Optional)

Enabled Graphic Packs:

• "Uncapped Framerate" (60fps)
• "Graphics" (TV resolution=1440p)

Logs (Optional)

No response

[goeiecool9999]

Could you try setting "Maximum pre-rendered frames" in the NVIDIA control panel to a lower value for cemu and see if that fixes the issue?

[Soreepeong]

Driver version 555.99 DCH; I'm not seeing that option from Manage 3D settings.

Closest thing is "Virtual Reality pre-rendered frames", which seemingly is 1 by default which is the minimum accepted value.

[goeiecool9999]

Aha okay. It's been a while since I've used an NVIDIA card. Although I read somewhere that they renamed it to or replaced it with low latency mode. Try messing with that setting. Also, what VSync setting are you using in Cemu?

[Soreepeong]

Using v2.0-86: Changing "Low Latency Mode" to "Ultra" did not result in any difference.

• On RTX 2070 Super, only "Double Buffering" made input latency consistently high, both in 1440p and 900p configuration from Graphic Pack. There were no issues while using "Off" and "Triple Buffering."
• On Intel UHD 770, the game played fine in any VSync mode on 900p. It consistently stuttered on 1440p.
  • RTX2070S and UHD770 are on the same PC; display is only displayed through RTX2070S.
• On Adreno on Snapdragon Elite, the game played fine in any VSync mode in 900p. It played smoothly on 1440p, but input latency kept increasing as time went, seemingly without upper limits.
  • Using v2.0-75 does not change this.

[Squall-Leonhart]

this is the same commit that reintroduced the flashing equipment subscreen in BOTW when using doublebuffering.

[goeiecool9999]

Hi, if it's not too much hassle, could you grab the CI build for #1290 and tell me if the issues persist?

[Soreepeong]

log.txt

Sadly it crashes while loading the game. Tried removing shaderCache and dump folders just in case, but it's the same. It ran once in the sixth attempt, but it would crash again in subsequent attempts at relaunching cemu and the game. For sanity check, it runs without crashes with previous builds.

When it did run though, the issue was fixed; no delays I could find.

From Event Viewer/Windows Logs/Application, there are two faulting offsets: 0x10c8f9 and 0x675284. log.txt generated seems to be the same across those runs.

[goeiecool9999]

Apparently the crashing DLL, graphics-hook64.dll, is a part of OBS. Did you have it running and if so can you check if everything works without OBS and if it also happens on the latest cemu release?

[Soreepeong]

• The PR: Without OBS running, it started fine every run attempts (10 times).
• v2.0-92: With OBS running, it crashes.
• v2.0-86, 80, 75: ditto.

Since I did use OBS to record gameplays in the past, I'd say that this is a bug introduced on OBS' side. Seems that the PR works fine without OBS running!

[Squall-Leonhart]

OBS is not compatible with overlay software from asus, evga, msi(rtss), etc as they (OBS) use a low effort implementation of detours which doesn't safely work with custom hooking methods.

RTSS is the only case where a user-settable compatibility method is available in the options that can be set globally or per game.

[Julinkk]

I have exactly the same problem, I compared using basic installations, applied exactly the same settings and the problem is on all versions from 2.0-77 up to 2.1