Skip to content

Commit

Permalink
Render before throttling
Browse files Browse the repository at this point in the history 
By putting the throttle step after the render step, the screen will be updated with the emulated frame's video output immediately instead of having to wait for the throttle sleep to complete.
In scenarios where running the core is relatively cheap (<< 1 / fps), this should noticably improve visual latency while playing.

For example, assuming a 60fps game (~16.7ms per frame), 5ms core update and 1ms render time, there will be a 10-11ms earlier render.
  • Loading branch information
@Morilli
Morilli committed Jun 26, 2024
1 parent b3a1d5e commit 722de0c
Showing 1 changed file with 1 addition and 2 deletions.
3 changes: 1 addition & 2 deletions src/BizHawk.Client.EmuHawk/MainForm.cs
View file
Original file line number Diff line number Diff line change
Expand Up @@ -880,9 +880,8 @@ public int ProgramRunLoop()
}

StepRunLoop_Core();
StepRunLoop_Throttle();

Render();
StepRunLoop_Throttle();

This comment has been minimized.

Sign in to view

Copy link
@CasualPokePlayer

CasualPokePlayer Jun 26, 2024 •
edited
Loading

Member

Doing this seems incorrect by a consistency perspective. You'd want to render at consistent intervals in order to have consistent frame presentation (i.e. minimal judder) and it's probably important for VRR monitors to properly understand the core's actual FPS. Core update time could potentially be fairly variable (albeit probably consistent mostly), the throtte step would ensure rendering is done at a consistent time. Doing this could be fine if VSync is enabled, which implicitly adds a wait within Render() (although it isn't enabled by default), or possibly when in Turbo/Fast Forward where we implicitly don't particularly care about consistency.

This comment has been minimized.

Sign in to view

Copy link
@Morilli

Morilli Jun 26, 2024

Author Collaborator

Yeah I've considered that while making this change, but I feel like it's still better to accept the potential inconsistency instead of just presenting the rendered output later.
The throttle step still exists, so if core time is unexpectedly short or long, it will be accounted for after the current frame is rendered.

I have not been able to see problems with this while playing, although I do not have a VRR monitor that I could potentially test with. I'd say unless this actually causes issues the advantage of this change is too great to not try it.
I have been able to see actual visual latency improvements with this change while playing (around one frame), and I've heard before that bizhawk supposedly has higher input delay than other emulators, and this could be the way to fix that.

This comment has been minimized.

Sign in to view

Copy link
@YoshiRulz

YoshiRulz Jun 27, 2024

Member

After this and the previous commit, my subjective experience on Linux is that the input latency is about the same. SMW is still unplayable.

This comment has been minimized.

Sign in to view

Copy link
@CasualPokePlayer

CasualPokePlayer Jun 27, 2024

Member

Is this using keyboard or a game controller here?

This comment has been minimized.

Sign in to view

Copy link
@YoshiRulz

YoshiRulz Jun 27, 2024

Member

Wireless USB keyboard lmao. But the point is there wasn't a noticable difference between the 2 builds.

This comment has been minimized.

Sign in to view

Copy link
@CasualPokePlayer

CasualPokePlayer Jun 27, 2024

Member

There's few limiting factors here really

  1. The speed at which the keyboard internally polls (this is probably 8 ms, maybe more)
  2. The speed which the X Server polls the keyboard. This is ???
  3. The speed which the X Server round trip takes (XQueryKeymap), which is ??? (I assume it's not that long / probably 1 ms at most)

These kinds of factors we can't really do much about, presumingly anyways Morilli's changes have most effect on Windows (which can do fairly low latency keyboard inputs)

This comment has been minimized.

Sign in to view

Copy link
@Morilli

Morilli Jun 27, 2024

Author Collaborator

SMW is still unplayable.

As in, input latency is too high to reasonable play the game? In that case it would make sense that a single frame (or less) of input latency improvement isn't noticable while playing.

// HACK: RAIntegration might peek at memory during messages
// we need this to allow memory access here, otherwise it will deadlock
Expand Down

0 comments on commit 722de0c

Please sign in to comment.