Patapon 1 input lag (I want errrradicate it)

[[Unknown]]

23933 06:02:814 user_main N[JIT]: Debugger\Breakpoints.cpp:320 BKP PC=08951214: s0=ffffffff; f0=00000000 - moment for ideal strike
26786 06:03:312 user_main N[JIT]: Debugger\Breakpoints.cpp:320 BKP PC=08951214: s0=ffffffff; f0=00000000 - moment for ideal strike
29890 06:03:815 user_main N[JIT]: Debugger\Breakpoints.cpp:320 BKP PC=08951214: s0=ffffffff; f0=00000000 - moment for ideal strike

From my perspective, this timing looks very close - every 500ms with only slight inaccuracy (by +/- 3ms.) So the overall frequency is good and correct. However, looking at the windows:

06:02:781 BKP PC=08951214: s0=ffffffff; f0=3e088888 (33ms too early)
06:02:814 BKP PC=08951214: s0=ffffffff; f0=00000000 (32ms just right)
06:02:846 BKP PC=08951214: s0=ffffffff; f0=3e088889 (32ms too late)

06:03:279 BKP PC=08951214: s0=ffffffff; f0=3e088888 (33ms too early)
06:03:312 BKP PC=08951214: s0=ffffffff; f0=00000000 (36ms just right)
06:03:348 BKP PC=08951214: s0=ffffffff; f0=3e088889 (32ms too late)

06:03:781 BKP PC=08951214: s0=ffffffff; f0=3e088888 (34ms too early)
06:03:815 BKP PC=08951214: s0=ffffffff; f0=00000000 (34ms just right)
06:03:849 BKP PC=08951214: s0=ffffffff; f0=3e088889 (32ms too late)

It becomes more murky. The "just right" window varies by a few ms - as much as 10% of the target window. Unfortunately, operating systems like Windows make this hard to control - it could be that your antivirus or some updater got a couple ms of CPU time right then, or something.

I've seen PSP timing vary - but it's probably tighter. I'd guess it never varies more than 1ms away from the timing it's supposed to have.

That being said, timing some additional functions might definitely help - maybe the window is just slightly off (even if the interval and length is correct) because of the GPU timing. Ultimately, if that's true, you will NEED "real clock sync" to get stable timing in this game.

Just to clarify: with real clock sync off, time looks like this:

Code:

REAL WORLD  ||      GAME
            ||
1ms         ||       1ms
...         ||       5ms
5ms         ||      33ms (frame finished)
keypress    ||   (pause)
...         ||
33ms        ||  keypress

In other words, within a frame, 33ms in this case, the game "fast forwards" and finishes that frame as fast as possible. If this takes 5ms in the real world, then it just waits until the next frame before waking up. The game thinks time is moving normally, but we're just fooling it.

That means if you press a button at 6ms, it literally cannot be seen by the game until 33ms. In fact, if you pressed a button at 3ms, it might even see that as a button being pressed at 16ms. This is because time moves faster for the game - it's time traveling in small hops between frames.

Real clock sync changes this. It still HAS TO time travel, but with real clock sync, it only time travels between 2ms intervals or so. So with that option enabled, as long as the game is not running behind, a button press will never come in more than 2ms off. However, getting more accurate than that on Windows is problematic, because Windows doesn't do sub-millisecond timing. It just doesn't.

-[Unknown]