Pcsx2: High Input Lag on 3D games

[Dogway]

PCSX2 version:
pcsx2-v1.5.0-dev-3138-gfbafd4420-windows-x86

PCSX2 options:

Software or Hardware mode indistinctly. Using Safe Preset

Plugins used:
Default:
GSdx32-AVX2
Spu2-X
LilyPad 0.12.1
FWNull Driver 0.7.0

Description of the issue:
There's a high game input lag in 3D based games, rarely below 6 frames of lag. Here are some tests done with frame advance using the minimum recorded frames for fastest event paths.

MGS3 Subsistance (6 frames)
GTA Vice City (6 frames)
GTA San Andreas (10 frames, 166ms!)
Sengoku Basara X (6 frames)
Tokyo Xtreme Racer 3 (7 frames)
Taiko Drum Master (6 frames)
Silent Scope (6 frames)
Time Crisis 3 (5 frames)
Capcom Fighting Evolution (4 frames)

Generally it's 6 frames of game input lag which is one of the highest recorded on current emulation software compared to Dolphin (5), Citra (4), Retroarch (4-5) and possibly Cemu and RPCS3 (they feel snappy)

How to reproduce the issue:

-Enable "Recording Tools"
-Load a game
-Press the frame advance hotkey
-Press a fast event triggering button on your pad
-Press again the frame advance hotkey as many times (counting them) until the event starts the animation

PC specifications:
Operating System: Windows 7 x64 SP1
CPU: Intel i5-4670K @ 4.1Ghz
GPU: Nvidia GeForce GTX 1070

[jacob1218]

I’ve noticed that too, what controller are you using?

[Dogway]

I use a 360 wireless controller but this is unrelated because I'm only measuring the emulation path input lag through the frame advance procedure. I guess judging by the picture you might already know but here is a good review of controller input lag.

[KrossX]

Is there data on PS2 + CRT input lag? It would be nice to have some, specially for GTA-SA. Might be tricky though as you could need a light in the controller for when a button is pressed and when pressure is greater than deadzone.

[tadanokojin]

Honestly I have a lot of problems with these numbers. Not the least of which is I can't independently verify any of them.

[KrossX]

You need a high speed camera and a controller that has a light on it.

3rd Strike 4.7
Dodonpachi DaiOuJou (White) 3

Dodonpachi seems like a good test point.

[tadanokojin]

I mean even barring a comparison to a control (which they don't provide), they aren't explicitly telling me where these numbers come from.

Here are some tests done with frame advance using the minimum recorded frames for fastest event paths.

What is "fastest event path" and how is it determined to be the fastest?

In DC2 I get numbers ranging from 4 to move the start menu cursor to 10 frames to swing a sword. A lot of which could probably be explained by animation blending and easing or natural delay introduced by the developers.

In Raw Danger! It's about 11 frames to move the cursor in the start menu, but I happen to know that game runs at 20fps internally.

Dolphin (5), Citra (4), Retroarch (4-5) and possibly Cemu and RPCS3 (they feel snappy)

Even if I granted this comparison made sense (I don't think it does). Where are these numbers even coming from?

[QuaiGoner]

In Flatout games input lag almost unplayable (fullspeed)

[Dogway]

What is "fastest event path" and how is it determined to be the fastest?

Do an array of tests in a game and take "the fastest" of the events. As you said in your DC2 example between the 4 and 10 frame lag take the fastest/shorter, 4. When you test enough games and events you start to paint a clear picture. I also think an input lag test with a real PS2 on a CRT should be made to clearly define the lag introduced through emulation, mind you the PS2 controller will likely introduce half a frame of input lag. Unfortunately I don't own a 60fps camera.

Even if I granted this comparison made sense (I don't think it does). Where are these numbers even coming from?

To be as unbiased as possible all tests were performed as explained on the issue description, with TAS tools using frame advance. Cemu and RPCS3 lack these tools.
While I also think PS2 2D games have at least 1 frame of game/emulation input lag, on 3D games it's specially jarring. When you add 6 frames to an extra frame for LCD and another one for the controller (at least), we are talking about 8 frames (133ms) minimum of input lag.

Edit: Found an input lag test with a PS2 3D game on a CRT. (3.86 frames of lag, accounting controller)

[tadanokojin]

As you said in your DC2 example between the 4 and 10 frame lag take the fastest/shorter, 4.

Yeah but there are thousands of things to test. I'm asking you for the specific things that gave you the number. We need to be able to reproduce it.

I also think an input lag test with a real PS2 on a CRT should be made to clearly define the lag introduced through emulation

I agree. That information would be useful.

To be as unbiased as possible all tests were performed as explained on the issue description, with TAS tools using frame advance. Cemu and RPCS3 lack these tools.

What games?
What did you test?
Where can I read the results?
What's your sample size for the other emulators?
Do we even need this comparison?

You're worried about bias but your sample size for PCSX2 is 9 games which I don't think is representative.

[Dogway]

I'm asking you for the specific things that gave you the number. We need to be able to reproduce it.

I test the fastest in gameplay, either jump, punch, turn (if digital input), etc. Eventually I also test Start to check it aligns to the measured minimums. These aspects are not usually given in tests because it's asummed you measured enough events and times, but if you need a specific event to reproduce I will post them later on.

I agree. That information would be useful.

I linked a video on my edit to a test with a real PS2, I didn't find what the display type was but in case it was an LCD I assume it to be one with zero lag. For reference Mega Man X8 (a 3D game) has an input lag of 64.459 (3.867 frames)

What games?
What did you test?
...

An average of an array of games similar to the one presented here. I test enough games until I find a pattern, obviously I'm not going to test the whole library but it's wise to pick games developed with the PS2 on mind, suggest games and I will try to test them. I did a study on input lag for 3D systems in retroarch that you can find on the link on top. As you can see they vary from 3 to 5 frames.

Now that we have a few comparison samples of real measurings on real hardware (Mega Man X8, Mega Man X7, Dodonpachi DaiOuJou (White)...), maybe we could run specific comparisons on PCSX2, but as I said, the events used for these measurings were not redacted so it depends on if you find them valid tests and/or valid games.

[sandman332]

Can confirm this, makes many first person shooter games unplayable.

[tadanokojin]

@Dogway

but if you need a specific event to reproduce I will post them later on.

I'd like to know what you are testing, yes, so others can test it an eliminate any external factors.
You can also post some block dumps so others can test.

In the meantime you can try disabling MTVU if it isn't already and seeing if that reduces latency any.

An average of an array of games similar to the one presented here.

Honestly just lose the comparison, you clearly can't or won't give me any details about it and frankly I don't think it would tell us much anyway.

Feel free to test other games in PCSX2, though. Jak series might be interesting.

maybe we could run specific comparisons on PCSX2

I agree. A good comparison against real hw would give us a delta and help us understand how much of the lag is emulation overhead.

[willkuer]

Wouldn’t it make more sense to check something the in-game button press memory address and check how many frames it takes to register the button press event?

Also wouldn’t you expect that the emulation overhead is game-independent as long as it’s not bottlenecked by the user’s system?

[Dogway]

Did more tests, MTVu has no effect, neither backend except for Yakuza.
I start invoking the events from the first playable scene in the game, then I test several events including Start and moving through the Start options to rule out intrinsic animation delays.

Testing through frame advance in Windowed Mode (OpenGl SW and HW, hyphen - means random not backend). If you need the profiles, let me know.

5     (Jump) (SW/HW) Jak and Daxter - The Precursor Legacy (USA)

4-5   (Jump) (SW/HW) Mega Man X8 (PAL)

4     (Jump) (SW/HW) God of War (PAL)

4     (Jump) (HW)    God of War II (PAL)

6     (Punch/Square)    (HW) Yakuza (USA)
6     (Start Menu Move) (HW) Yakuza (USA)
7     (Move/Start)      (HW) Yakuza (USA)
11    (Punch/Square)    (SW) Yakuza (USA)
11    (Start Options)   (SW) Yakuza (USA)
12-13 (Move/Start)      (SW) Yakuza (USA)

6     (Start Options)     (SW/HW) Gran Turismo 4 (USA)
5     (Brake/Camera View) (SW/HW) Gran Turismo 4 (USA)

7-8   (Jump)        (SW/HW) Kingdom Hearts (PAL)
6     (Start)       (SW/HW) Kingdom Hearts (PAL)
5     (Start Items) (SW/HW) Kingdom Hearts (PAL)

9-10  (Start/Start Options/Jump) (SW/HW) Ico (PAL)
15    (Move)                     (SW/HW) Ico (PAL)

4     (Start)     (HW) Monster Hunter (PAL)
4     (Move/Turn) (HW) Monster Hunter (PAL)
5     (Start)     (SW) Monster Hunter (PAL)
4-5   (Move/Turn) (SW) Monster Hunter (PAL)

5     (Start)        (SW/HW) Tekken 5 (USA)
6     (Cross/Square) (SW/HW) Tekken 5 (USA)

4     (Start)              (SW/HW) Grand Theft Auto III (PAL)
5     (Car Brake -Square-) (SW/HW) Grand Theft Auto III (PAL)
6     (Jump -Square-)      (SW/HW) Grand Theft Auto III (PAL)

10    (Start/Start Options/Move Turn/Car Brake) (SW/HW) Grand Theft Auto - San Andreas (PAL)
14    (Jump)                                    (SW/HW) Grand Theft Auto - San Andreas (PAL)

10-11 (Shoot/Crouch)        (SW/HW) Black (PAL)
12-13 (Start/Start Options) (SW/HW) Black (PAL)

[water111]

The input latency is confusing. I measured Jak 1's input latency with a light on a controller and a high speed camera.

On PS2, I would expect around 5 frames:

• 0 : button pushed
• 1 : IOP reads controller (once per frame)
• 2 : EE receives IOP DMA with button press and calls ja-push
• 3 : animation system runs, puts animation frame in next frame's DMA list
• 4 : VU processes DMA list and writes to frame buffer
• 5 : frame with animation is visible

With the camera, I measured between 5 and 6 frames of latency (usually 6) on a PS2 with a CRT TV.

On PCSX2, I would expect another frame to read the controller, and probably a few more on graphics.
But I got between 11 and 18 frames of latency. (11,13,14,12,13,17,13,18,11,15)

I am not sure where the huge latency is coming from, but I did find two interesting things:

1). In PCSX2, some game frames are just not shown. Even if the game is internally running at 60 fps and PCSX2 is running full speed, it will just skip frames at random. I found an animation which is 17 frames, and plays as frame 1,2,3,....,17 on a real PS2. In PCSX2, some frames a just skipped, so you saw 1,1,3,4,5,6,6,8,9,9,11,12,13,13,13,16,17. Watch this video and see how it is choppy in the second half https://www.youtube.com/watch?v=IMjHCIwb7hc, which matches the high speed video of the screen. The game is running at 60 fps internally here, or the numbers at the top would turn red.

2). The EE/VU timing is very off, so the games may sometimes be running at a different frame rate on PCSX2 and PS2. Jak mostly runs at the right frame rate, but in certain areas, it internally runs at 30 fps on PCSX2 where PS2 runs at 60 fps. I think this is because some EE code takes around 2x more cycles than it should. See the game profiler here when the game goes at 30 fps in PCSX2: https://imgur.com/a/WwBHpY8 . The upper bar is EE, and the yellow/white sections are an EE-based renderer. This fits within 100% on PS2, but is over 120% on PCSX2. The lower bar is VU1, which has around 2x higher utilization on PS2.

[tadanokojin]

I found an animation which is 17 frames, and plays as frame 1,2,3,....,17 on a real PS2. In PCSX2, some frames a just skipped, so you saw 1,1,3,4,5,6,6,8,9,9,11,12,13,13,13,16,17.

Interesting. Just spitballing but I wonder if the alt vsync PR addresses this any,

[tadanokojin]

I ran some tests from @Dogway's results. I ran these tests by buffering the input for 2 frames. I'm including that buffering in my results. All tests are NTSC-U.

In GTA III I tested the pause menu. I found it was 4 or 5 frames before the background appears. I did note however that the audio cue happens on the 3rd frame.
https://youtu.be/_KJMuUMM5T8

In GT4 I got about 6 frames for the audio cue and the menu begins to appear on the 7th. Exiting it I'm noticing it's only 3 frames for the audio cue.
https://youtu.be/FC2Y6aQakjw

In Ico, which was the one I was most interested to test because of the high number. I tested it by holding the analog stick in the direction opposite where the character was facing and waiting for the character to move. The result I got was 8 frames. Which is a little more than half what Dogway is reporting. Not sure if this is due to differences in regions or if Dogway tested a different move animation.
https://youtu.be/hW15-DHc_a8

I got 10 frames for the start menu to appear.
https://youtu.be/myE6cU5hZ1E

[sandman332]

So, are there any band-aid fixes or anything that can be done from the users end to somewhat fix this issue? Makes all the games I have played almost unplayable and some definetly are.

[mirh]

Well, for starters, mods could have not deleted my comment referencing the stuttering problems of the nvidia driver #2307. Considering we have yet to solve that hot potato, I'm not sure we really can take at face values results from geforces (unless under linux)

I wonder what best case input lag of the emulator could be then? Say, with unlocked framerate and in the bios menu.

[ramapcsx2]

The upper bar is EE, and the yellow/white sections are an EE-based renderer. This fits within 100% on PS2, but is over 120% on PCSX2. The lower bar is VU1, which has around 2x higher utilization on PS2.

@water111
Could you share how you got into that performance counter debug mode?
It's probably using hardware that PCSX2 doesn't fully / correctly emulate, so I wouldn't trust it too much, but I'd like to try this with modified VRender / VBlank timing.
Maybe it makes a difference.

[water111]

These performance bars should work correctly for EE - they are just based on the timers which PCSX2 does correctly. Other performance menus aren't emulated correctly and display all zeros, I think because PCSX2 doesn't support the EE performance counter registers. The VU bar is a little weird because of how PCSX2 handles VU1 timings.

Here's a link to a patch that you can apply to PCSX2 to get into this mode. It's a bit of hack because it needs to emulate a dev kit with extra RAM and patch several memory values at specific times.

https://gist.github.com/water111/e4a0af85968daad1ac478573ae07b48c

(I think it also changes the vsync timing, so maybe you want to remove this)

If you boot Jak and daxter NTSC/PAL/Japan version, it should start up in the debug mode. Then press L3 to open the menu, then click Display, then profile.

I am fairly certain this isn't a vsync timing issue, but instead an EE timing issue. Most of the time is spent in a renderer where almost every instruction can be dual issued.

[ramapcsx2]

That's insanely clever xD
Thanks!

[MrCK1]

@Dogway I'm assuming this is still an issue for you or has anything changed in the recent dev builds?

[sandman332]

Something tells me this is still a pretty big issue.

[mirh]

People on reddit were still reporting this
(even though ofc "everybody has it when it comes to complaining, but nobody when it's time to understand")

[Dogway]

As a headnote, I'm waiting to have a 1.6.0 RC to test, the one I downloaded wasn't built with recording tools enabled.

[tadanokojin]

They'll be disabled for the release due to some issues with it. You'll have to stick with the dev builds for now.

[Dogway]

last dev build has it also disabled...

My bad: copied over the wrong file

[tadanokojin]

Just checked dev 3391 and it's enabled.

[Dogway]

A little update with the most affected titles (dev 3391):

9-10  (Start/Start Options/Jump) (SW/HW) Ico (PAL)
7     (Turn over/Lang Sel Menu)  (SW/HW) Ico (PAL)

10-11 (Shoot/Crouch)        (SW/HW) Black (PAL)
12-13 (Start/Start Options) (SW/HW) Black (PAL)

[mirh]

Thank you for sticking with us, and even reporting precise numbers.
Did we already rule out this could have something to do with the problems with nvidia cards and stuttering?
Can you try to put EnableVsyncWindowFlag=enabled in pcsx2_ui.ini, set aspect ratio to "Fit To Window/Screen" and play in fullscreen?

[Dogway]

This is a little different issue although I would also like to see stutter improve.
I'm frameskipping after an input event in pause mode so it's the internal lag of the system/emulator what is measured, I will test GTA as well but things don't look promising. Since the minimum recorded is 4 frames (GOW) it tells there's room for improvement for most other between 5 and 6 frames (leaving out input, monitor and buffer/vsync related lag), maybe dissecting the most offending ones can reach to some conclusions (Black, GTA SA).

[ABU3BGE]

so is there a fix ?

[phantomolecule]

I've never had this problem until very recently . Strangely enough it happens on dev build 3391 as well as an older dev 3306 build (I thought it might've been because I updated). Other emulators and games work just as expected, and the delay is present even in the "test device" section of LilyPad, not just in games, so it doesn't seem to have anything to do with graphics cards or performance. Hopefully a fix is in the works as there seems to be many people affected, and the delay is significant enough that I just won't use pcsx2 for the time being
EDIT: thought maybe it was my DS3 drivers so I tested it with keyboard and mouse, no change, same input delay.

[KrossX]

LilyPad has a test device thing? You could try the other APIs and see if there's a difference. Other than that, there's the xpad and pokopom plugins that could be checked with xinput controllers.

[ABU3BGE]

i try all plugin nothing changed

[phantomolecule]

Yeah if you right click your input device under "device diagnostics" there's an option to "test device", it brings up a pretty simple list of all the inputs and shows when the value changes. Thanks for the suggestion, just tried the other plugins in 3391, still no change unfortunately.

[ABU3BGE]

i think i fixed it or at least lower the delay
tell the dev to see what the problem was
the fix is simple uncheck automatic gamefix you can find it under system .
if anyone know what is used in automatic gamesfix or can i find the ini file for the automatic fix not the manual fix tell me .
i tested it with shinobido it kind of fixed it
when you try it tell me if it worked and what was the game
have fun

[phantomolecule]

Interesting, I'm glad you're able to enjoy your game more than you could before. That it only lessened the delay makes me think it might have not fixed the real underlying issue. My issue might be a little different, as I see the delay even when testing the gamepad in PCSX2 outside any games running, using "test device" under "device diagnostics". In fact, the keyboard responds the same way as the controller when tested, in or out of game, but only inside PCSX2. Maybe I should open up a new issue? As I'm realizing this topic is specifically for 3D games.

[KrossX]

Well, ingame lag would still be relevant I think. You could open up a new issue about lag on the lilypad test window. It could be a bug with how the input is polled and presented or intentional to avoid the test window from being flickery.

[phantomolecule]

I can't see how it would be an issue specifically with the lilypad test window as the issue is still present using other controller plugins, as well as consistently across all games I've tried (various games I've had no problems playing in the past). The test window was just how I isolated performance and specific games as a factor. Downloading a fresh copy of pcsx2 and confirming nvidia control panel vsync is off still hasn't made it budge, very strange.

[KrossX]

LilyPad Diagnostic Window Timer

The plugin creates its own window, it does not go through the emulator loop. The link is for the diagnostics window that has its own message handling. You can see it sets a 200ms timer to update the information. Thus, this was intentional, possibly to avoid a flickering dialog window. It's a window just to test if the device is working, not intended to be a latency benchmark.

[phantomolecule]

Very interesting, thanks for clearing that up. All the more bizarre that the delay is seemingly identical to the one I find in-game, although 200ms seems a bit high. Admittedly my experience with input delay is mostly in music production, but the gap seems to be around 100ms or so, enough to make a difficult racing or action game unplayable. ATM I'm messing with the framelimiter to see if I can increase or decrease the delay based on framerate, seeing as how I can't rule out graphics card or performance with a separate diagnostic. No change so far unfortunately.

[tadanokojin]

Try setting in PCSX2_vm.ini, think it's called VSyncQueueSize or something.

[mirh]

SO, AS I WAS SUSPECTING:
After my fifth or sixth outburst on reddit, a very collaborative user stood up and helped me with some tests (all of this was on an intel gpu, on w10, with on capcom fighting jam).
And once we could manage to get some shape or form of exclusive fullscreen, every input lag problem was solved, and "comparable to real PS2" (or 1 frame behind at most every now and then, possibly just being introduced by the display)
The real hardship was getting there in the first place though.

It turns out for some reason "put EnableVsyncWindowFlag=enabled in pcsx2_ui.ini" wasn't working for him.
Thankfully he knew about W10's fullscreen optimizations that convert every dx11 borderless fullscreen window to fullscreen.
And as for opengl, were they don't work, we ended up just forcing the famous WS_POPUP flag with winspy++.
(and of course you still need fit to screen)

Please, anybody test that.

[tadanokojin]

And how was this measured?

[mirh]

With a 60fps camera.

[water111]

Here is some data. This is unrelated to the fullscreen stuff, but is related to games feeling laggy/unplayable.

I ran jak 1 and set my capslock button to be jump. I filmed with a 120 fps phone camera, and measured from caps lock LED on to jumping animation start. With the latest PCSX2, it took 30 video frames (15 PS2 frames) for the animation to start. I ran it a few more times and got 15, 17, 19, 15. This is similar to the numbers I got before.

Then I ran the same thing on the PS2. Note that my TV caught fire recently so I was using a component to VGA box that probably has some lag, and a crappy VGA monitor which probably also has some lag. From finger on button to jump, it took 18/20 video frames (9 to 10 PS2 frames). I suspect that there are a few frames of latency in the converter from how it feels, but I don't have hard data. Note that I was measuring from when my finger touched the button, not when the button was pushed, because it was too hard to judge when the push actually happens.

I noticed that PCSX2 also was dropping a lot of frames for me, generally the UI was stuttering, and there was a freeze of the UI for around 3 seconds on startup. I checked if the UI was getting blocked on some OS thing with ETW and it wasn't - it was at 100% CPU usage during the freezes. I ran it in the VS debugger and noticed it happens at roughly the same time as when there are "access violations" caused by the JIT.

I dug a little deeper and found that there's a UI event generated every time the EE recompiler exits recompiled code. See SysCoreThread.cpp, in DoCpuExecute(). The Cpu->Execute() function pointer will point to recExecute in iR5900-32.cpp when the EE recompiler is running, which returns on every page fault (happens whenever new code is encountered and needs to be compiled).

The UI event is UI_EnableSysActions, which is kind of slow because it does some stuff related to the save slots and their names. It is really silly to put this UI stuff in the CPU execute / recompiler loop, as it can exit a huge number of times when a game first runs, or if the game requires a lot of recompiling.

If you comment out the call to UI_EnableSysActions() inside of SysCoreThread::DoCpuExecute, the game becomes much less choppy. Also, the latency decreases from 15 frames to 11 frames. I don't understand PCSX2's UI design, but everything seems to work correctly with this commented out.

Adding this change makes PCSX2 playable for me, and otherwise it is very unpleasant. If anybody is more familiar with the PCSX2 UI, it would be great to get an explanation of how this UI_EnableSysActions function is supposed to work, and I can work on a better fix than just commenting it out.

[pixelherodev]

I dug a little deeper and found that there's a UI event generated every time the EE recompiler exits recompiled code. See SysCoreThread.cpp, in DoCpuExecute(). The Cpu->Execute() function pointer will point to recExecute in iR5900-32.cpp when the EE recompiler is running, which returns on every page fault (happens whenever new code is encountered and needs to be compiled).

Ohhh, that's _brilliant_! Page faulting on unknown code so it can be compiled on demand!

... not entirely on-topic, I know; sorry, been obsessively playing with dynarecs lately.

[ramapcsx2]

Yeah, this is highly unusual code, but it is there for a good reason. (I don't claim to understand any of it, mind).
So it's possible that there was much less GUI code to check initially, but it grew in complexity over time.
In that case, a redesign of the slow parts would probably be a good idea.
Of course this requires someone who fully understands all the implications to do it :)

But yeah, the GUI hooks do serve an important function, as weird as they seem to be.

[ramapcsx2]

Oh yeah, the savestates...
IIrc, they expect the recompiler do be in a well defined state when saving and loading.
That could be the issue.

Related code is also used for suspending / resuming threads, and that is kind of all the GUI functionality.

[tadanokojin]

With regards to @mirh's report

I had a lengthy conversation with him on discord. He neither verified the result himself or even asked for the videos and when I argued him into giving me the videos he gave me 4 videos but none were a control.

I was able to verify that none of the videos seemed any different in terms of lag (they vary in settings such as FSO enabled or disabled). Perhaps said user will come forward directly and give us some more insight as to why they think this improves the situation for them. Until then I'm calling it inconclusive.

On a more positive note, @RedPanda4552 has a high-speed camera and was willing to do some testing with the flag enabled. We performed these tests with his phone camera using the capslock key mapped to a button, allowing us to see the button press. I've put the two videos side by side and additionally I've slowed the videos down further to 25% so you can see the frame by frame.

https://i.imgur.com/9xwuCUE.mp4

There doesn't appear to be much difference if you ask me. Maybe FSE is a frame faster on some frames but input seems to register about the same time. I'll include the raw recordings so you can count the frames yourself.
Here are the raws

If anyone has any other aspect of FSE they'd like us to test or any issues they'd like us to address with the test please let me know.

[tadanokojin]

@ramapcsx2

Yeah, this is highly unusual code, but it is there for a good reason. (I don't claim to understand any of it, mind).

Well I have done gui code so I'll take a stab at it for you. WX is basically a big while(true) loop that processes events every iteration. I/O access is blocking, not only blocking but dependent on I/O speed. Which means the loop stalls to do blocking code. Loop stalling means UI cannot process new events or update, making it hang. Now spam this a bunch of times and you have issues.

But yeah, the GUI hooks do serve an important function, as weird as they seem to be.

No one thinks the hooks themselves are weird. You have to do that obviously to let the gui know about important events from core. What is silly is how it was done. Now blocking I/O code might have been added later, but if the update worked as expected it likely wouldn't be too much an issue. Clearly whoever added it didn't consider this caveat to the recompiler that it will exit a ton under certain circumstances.

Anyway I suspect this function at the end of _SaveLoadStuff:

void Sstates_updateLoadBackupMenuItem(bool isBeforeSave)
{
    wxString file = SaveStateBase::GetFilename(StatesC);

    if (!(isBeforeSave && g_Conf->EmuOptions.BackupSavestate))
    {
        file = file + L".backup";
    }

    fprintf(stderr, "test");
    sMainFrame.EnableMenuItem(MenuId_State_LoadBackup, wxFileExists(file));
    sMainFrame.SetMenuItemLabel(MenuId_State_LoadBackup, wxsFormat(L"%s %d", _("Backup"), StatesC));
}

Call to wxFileExists is likely blocking I/O call. Other save state stuff is cached so I don't think I/O happens much. Obviously spamming the event system blocking or otherwise is still a bad idea.

Best way to fix it IMO is to find a way to let the gui know about the change in VM state without spamming the gui thread a ton about it.

[mirh]

he gave me 4 videos but none were a control.

I already said they were there now.
And in a very quick game like street fighter, those ~4 additional frames can mean a +50% latency increase from the best case to the worst.

There doesn't appear to be much difference if you ask me.

Indeed. But then there didn't seem to be any particular difference compared to an actual PS2 either.
Which would mean this whole issue is kind of a dupe.

So, we are still kind of missing something (including data points from more people as I was asking above).
So far we have the following contenders AFAIK (not exclusive with each other):

• OS compositing getting in the way (perhaps more apparent on slower PCs with little-to-none cpu time/cores to dedicate to DWM)
• This problem with wx locking up the UI/IO
• Hyper-threading (which could or could not just be dependent on the previous point)

[Immersion95]

With regards to @mirh's report

I had a lengthy conversation with him on discord. He neither verified the result himself or even asked for the videos and when I argued him into giving me the videos he gave me 4 videos but none were a control.

I was able to verify that none of the videos seemed any different in terms of lag (they vary in settings such as FSO enabled or disabled). Perhaps said user will come forward directly and give us some more insight as to why they think this improves the situation for them. Until then I'm calling it inconclusive.

On a more positive note, @RedPanda4552 has a high-speed camera and was willing to do some testing with the flag enabled. We performed these tests with his phone camera using the capslock key mapped to a button, allowing us to see the button press. I've put the two videos side by side and additionally I've slowed the videos down further to 25% so you can see the frame by frame.

https://i.imgur.com/9xwuCUE.mp4

There doesn't appear to be much difference if you ask me. Maybe FSE is a frame faster on some frames but input seems to register about the same time. I'll include the raw recordings so you can count the frames yourself.
Here are the raws

If anyone has any other aspect of FSE they'd like us to test or any issues they'd like us to address with the test please let me know.

Hi, I was the one doing the tests with the great help of @mirh so i can answer some of the questions.

The problem with the input lag for me was the forced buffering which was because of Borderless Windows (I thought).

@mirh explained to me that there was a way to let DWM promotes PCSX2 to an hybrid fullscreen without any buffering done.

The test is easy, first we need to disable Vsync from PCSX2 and see :

• Tearing = No buffering from DWM = Less input lag
• No Tearing = Buffering from DWM = More input lag

I concluded that only these combinations make the tearing appear :

• EnableVsyncWindowFlag=enabled in pcsx2_ui.ini
• FSO has to NOT be disabled in the properties (needed with Nvidia but unsure with Intel GPU)
• Fit To Window/Screen (it has to be stretched to fit all the screen)
• Intel GPU = DX11 and (nothing else)
• Nvidia = OpenGL and (nothing else)

This allow to reduce the lag a lot as DWM buffering + Vsync was horrendous !
Now I can play PCSX2 with reduced input lag, almost similar to the real PS2. The only problem is that the TV has to change the Ratio to be accurate, is there any way to make it work without "Fit To Window/Screen" ?

Also, would it be possible to include EnableVsyncWindowFlag by default ?

Also, thanks a lot for your hard work PCSX2 Team !

[RedDevilus]

What about Gsync and Freesync? Could be worth looking at too if someone has a monitor like that.

[tadanokojin]

@Immersion95 can you provide any testing and information about your PC.

[Immersion95]

What information ?

[tadanokojin]

Specs. CPU/GPU, driver versions, anything that can be helpful in diagnosing the issue.

[Immersion95]

I tested on 3 different computers with Windows 10 1909, the only difference were graphic cards.

Intel GPU -->Needs DX11 to make it work
Nvidia -->Needs OpenGL to make it work

Aren't you able to reproduce this ?

Best regards.

[tadanokojin]

No I can't, that's why I'm asking you for specs.
What graphics card? What CPU? What driver?

[Immersion95]

Yes, sorry I didn't understand :

• PC 1 : i7 4790k + Intel® HD 4600 + Drivers 15.40
• PC 2 : i7 4790 + Nvidia GTX 1650 Low Profile + Drivers 446.14

[tadanokojin]

And this was with KOF 2000? Did you do any camera test or was this by feel alone?

[Immersion95]

I did the tests with a phone which can record at 60fps with a lot of games but the tests with @mirh were done with Capcom Fighting Jam.

I bought an OSSC and waiting for it to arrive, I will then be able to compare it with the same display lag and also same controller (Wireless DS4 & Wireless DS4+Brook for the PS2).

[gamer2key]

I also suffer from input lag problems. Not so much but enough to be annoying playing Tekken or games that require extreme precision. I have tried on many rigs over the years and this problem has always bothered me. I hope the team can fix it sooner or later because I love pcsx2.

[ABU3BGE]

Did anyone tried disabling gamefix it did fix some of the lag not all of it

[Minion77777]

I thought i was the only one facing this input lag issue... hope it can be fixed! Dragon Ball Z Budokai Tenkaichi 3 is unplayable for me for this issue.

[phantomolecule]

Just chiming in to say with the newest Nvidia drivers and newest pcsx2 this issue is still present after randomly starting months and months ago. even on a new low latency monitor, everything else including other emulators are very responsive. happens with keyboard and mouse or gamepad, software or hardware, gamefixes or no, gamehacks or no, fullscreen or windowed, independent of performance, across all games, in menus and in-game etc. I’ve tested it from every angle I can imagine and it seems there’s an extremely consistent input delay that only affects pcsx2. it’s a shame because for all its problems it was my favorite emulator, but randomly it became unusable, even older versions. from what I’ve seen online this affects many people and no solution has been found.

[Immersion95]

Just chiming in to say with the newest Nvidia drivers and newest pcsx2 this issue is still present after randomly starting months and months ago. even on a new low latency monitor, everything else including other emulators are very responsive. happens with keyboard and mouse or gamepad, software or hardware, gamefixes or no, gamehacks or no, fullscreen or windowed, independent of performance, across all games, in menus and in-game etc. I’ve tested it from every angle I can imagine and it seems there’s an extremely consistent input delay that only affects pcsx2. it’s a shame because for all its problems it was my favorite emulator, but randomly it became unusable, even older versions. from what I’ve seen online this affects many people and no solution has been found.

You have to have these conditions to enable the hybrid fullscreen which disable the frame buffering :

• EnableVsyncWindowFlag=enabled in pcsx2_ui.ini
• OpenGL SW or HW for Nvidia
• DX11 SW or HW for AMD/Intel (OpenGL can work but I'm not sure)
• Fit to screen (yes you will think it's useless but it's not until https://github.com/PCSX2/pcsx2/pull/3588 is merged)
• DO NOT disable Full Screen Optimizations in the pcsx2.exe properties (right click on Windows 10)

If you want to use Vsync, please disable frame limiter from PCSX2 and use Vsync from the Nvidia driver config or with RTSS/Scanline Sync. You can use PCSX2 Vsync but it's not that great regarding input lags.

You will normally see tearings when Vsync is off, this will confirm that you do not have buffering and the lowest possible input lag

I personally use Scanline Sync with RTSS (-1 in the settings) and the results are almost perfect !

Edit : Forgot the flag

[bigol83]

I cannot manage to make tearing appear. Using opengl and the settings @Immersion95 used it only gives me stuttering, but never tearing.

Do i have to use a particular build?

[phantomolecule]

Just chiming in to say with the newest Nvidia drivers and newest pcsx2 this issue is still present after randomly starting months and months ago. even on a new low latency monitor, everything else including other emulators are very responsive. happens with keyboard and mouse or gamepad, software or hardware, gamefixes or no, gamehacks or no, fullscreen or windowed, independent of performance, across all games, in menus and in-game etc. I’ve tested it from every angle I can imagine and it seems there’s an extremely consistent input delay that only affects pcsx2. it’s a shame because for all its problems it was my favorite emulator, but randomly it became unusable, even older versions. from what I’ve seen online this affects many people and no solution has been found.

With Nvidia, you have to have these conditions to enable the hybrid fullscreen which disable the frame buffering :

• OpenGL SW or HW (and nothing else)
• Fit to screen (yes you will think it's useless but it's not until #3588 is merged)
• DO NOT disable Full Screen Optimizations in the pcsx2.exe properties (right click on Windows 10)

If you want to use Vsync, please disable frame limiter from PCSX2 and use Vsync from the Nvidia driver config or with RTSS/Scanline Sync. You can use PCSX2 Vsync but it's not that great regarding input lags.

You will normally see tearings when Vsync is off, this will confirm that you do not have buffering and the lowest possible input lag

I personally use Scanline Sync with RTSS (-1 in the settings) and the results are almost perfect !

Thanks for the response. I was sure I had tried these, but seeing your reply I got excited and decided to double check everything again.
-I only use OpenGL, but I double checked that, tried HW and SW for good measure.
-Double checked that I was using the "fit to window/screen" option.
-Recently I did disable the framelimiter under GS window and switched to using RTSS instead, but went ahead and double checked that just in case. Also tried the scanline sync -1 because I was curious but noticed no change.
-The "disable fullscreen optimizations" in the .exe properties I wasn't sure of so I double-checked that and it hadn't been turned on, so no problem there.

I've had my 1050ti for a couple of years now, long before this issue started happening. what's odd is I didn't even upgrade my pcsx2 to make it happen, one day it just became unusable with a very noticeable change in responsiveness. I don't know the exact numbers, but to give you an idea, I can notice the difference between a wireless usb controller and a wired one in action games like sekiro, but that amount is negligible compared to the latency of the issue I've been having with pcsx2. I know I've said it before but pcsx2 didn't always behave this way (at least on my computer), so I know it's not just a problem with ps2 emulation or pcsx2 itself. The whole thing is completely bewildering to me.

[Immersion95]

Thanks for the response. I was sure I had tried these, but seeing your reply I got excited and decided to double check everything again.
-I only use OpenGL, but I double checked that, tried HW and SW for good measure.
-Double checked that I was using the "fit to window/screen" option.
-Recently I did disable the framelimiter under GS window and switched to using RTSS instead, but went ahead and double checked that just in case. Also tried the scanline sync -1 because I was curious but noticed no change.
-The "disable fullscreen optimizations" in the .exe properties I wasn't sure of so I double-checked that and it hadn't been turned on, so no problem there.

I've had my 1050ti for a couple of years now, long before this issue started happening. what's odd is I didn't even upgrade my pcsx2 to make it happen, one day it just became unusable with a very noticeable change in responsiveness. I don't know the exact numbers, but to give you an idea, I can notice the difference between a wireless usb controller and a wired one in action games like sekiro, but that amount is negligible compared to the latency of the issue I've been having with pcsx2. I know I've said it before but pcsx2 didn't always behave this way (at least on my computer), so I know it's not just a problem with ps2 emulation or pcsx2 itself. The whole thing is completely bewildering to me.

Please see my updated comment with the flag

[Immersion95]

I cannot manage to make tearing appear. Using opengl and the settings @Immersion95 used it only gives me stuttering, but never tearing.

Do i have to use a particular build?

Please check my updated comment, do you have a Nvidia GPU ?

[bigol83]

I cannot manage to make tearing appear. Using opengl and the settings @Immersion95 used it only gives me stuttering, but never tearing.
Do i have to use a particular build?

Please check my updated comment, do you have a Nvidia GPU ?

Yes i have an nvidia gpu, after i changed the flag it works. Thanks.

[phantomolecule]

Just chiming in to say with the newest Nvidia drivers and newest pcsx2 this issue is still present after randomly starting months and months ago. even on a new low latency monitor, everything else including other emulators are very responsive. happens with keyboard and mouse or gamepad, software or hardware, gamefixes or no, gamehacks or no, fullscreen or windowed, independent of performance, across all games, in menus and in-game etc. I’ve tested it from every angle I can imagine and it seems there’s an extremely consistent input delay that only affects pcsx2. it’s a shame because for all its problems it was my favorite emulator, but randomly it became unusable, even older versions. from what I’ve seen online this affects many people and no solution has been found.

With Nvidia, you have to have these conditions to enable the hybrid fullscreen which disable the frame buffering :

• OpenGL SW or HW (and nothing else)
• Fit to screen (yes you will think it's useless but it's not until #3588 is merged)
• DO NOT disable Full Screen Optimizations in the pcsx2.exe properties (right click on Windows 10)

If you want to use Vsync, please disable frame limiter from PCSX2 and use Vsync from the Nvidia driver config or with RTSS/Scanline Sync. You can use PCSX2 Vsync but it's not that great regarding input lags.
You will normally see tearings when Vsync is off, this will confirm that you do not have buffering and the lowest possible input lag
I personally use Scanline Sync with RTSS (-1 in the settings) and the results are almost perfect !

Thanks for the response. I was sure I had tried these, but seeing your reply I got excited and decided to double check everything again.
-I only use OpenGL, but I double checked that, tried HW and SW for good measure.
-Double checked that I was using the "fit to window/screen" option.
-Recently I did disable the framelimiter under GS window and switched to using RTSS instead, but went ahead and double checked that just in case. Also tried the scanline sync -1 because I was curious but noticed no change.
-The "disable fullscreen optimizations" in the .exe properties I wasn't sure of so I double-checked that and it hadn't been turned on, so no problem there.
I've had my 1050ti for a couple of years now, long before this issue started happening. what's odd is I didn't even upgrade my pcsx2 to make it happen, one day it just became unusable with a very noticeable change in responsiveness. I don't know the exact numbers, but to give you an idea, I can notice the difference between a wireless usb controller and a wired one in action games like sekiro, but that amount is negligible compared to the latency of the issue I've been having with pcsx2. I know I've said it before but pcsx2 didn't always behave this way (at least on my computer), so I know it's not just a problem with ps2 emulation or pcsx2 itself. The whole thing is completely bewildering to me.

Please see my updated comment with the flag

Thanks for the quick reply, hadn't tried enabling vsync window flag in the ini. I did so but when I checked it after I ran a game and there was no change, I saw that it was changed back to disabled, and when I set it to "read only" after enabling it again, pcsx2 seems to be creating new .tmp files with the flag back to disabled. Still no change, any idea why pcsx2 would be refusing to use that ini setting?

[Immersion95]

Thanks for the quick reply, hadn't tried enabling vsync window flag in the ini. I did so but when I checked it after I ran a game and there was no change, I saw that it was changed back to disabled, and when I set it to "read only" after enabling it again, pcsx2 seems to be creating new .tmp files with the flag back to disabled. Still no change, any idea why pcsx2 would be refusing to use that ini setting?

Start fresh and change EnableVsyncWindowFlag="disabled" to "enabled"

[RedDevilus]

Please don't use that many quotes, it's becoming hard to follow. Thank you.

[phantomolecule]

Start fresh and change EnableVsyncWindowFlag="disabled" to "enabled"

Using the quotes seems to have gotten it to stick in the ini, and the difference between the two is noticeable. Thank you very much! I don't remember pcsx2 ever having any extra delay at all (when compared with any other emulator) until a little less than a year ago, but with these fixes it's at a level that's tolerable/playable in less response time orientated games. I hope some progress can be made with it, or at least someone could figure out why the jump backwards in progress with this issue, but all the same I'm thankful for your help, it's a big difference.

Edit: It's also introduced major screen tearing, which wasn't a necessary compromise before whatever bug/issue has caused this, so I'll still be waiting until things get patched up. Oh well, I'm sure the team is working hard enough as is, and I'm grateful for the times I've had with the emu.

Please don't use that many quotes, it's becoming hard to follow. Thank you.

My bad, I'll try to be mindful of that in the future.

[Immersion95]

Edit: It's also introduced major screen tearing, which wasn't a necessary compromise before whatever bug/issue has caused this, so I'll still be waiting until things get patched up. Oh well, I'm sure the team is working hard enough as is, and I'm grateful for the times I've had with the emu.

It's normal to have tearings without Vsync.

Now that you observe tearings, you can re-enable Vsync as you now know that buffering is definately disabled.

You can use PCSX2 Vsync but I suggest to use RTSS/Scanline Sync with -1 with framelimiter disabled.

I didn't have great results then so I enabled the framelimiter and manually changed the fps to match my refresh rate of 60.0 instead of 59.94 :

• Open PCSX2_vm.ini
• Change to "FramerateNTSC=60.00"

With that configuration, the input lag is realy reduced and the fps is smooth. I sometimes see really small tearings but it doesn't hinder the experience.

[phantomolecule]

It's normal to have tearings without Vsync.

Now that you observe tearings, you can re-enable Vsync as you now know that buffering is definately disabled.

You can use PCSX2 Vsync but I suggest to use RTSS/Scanline Sync with -1 with framelimiter disabled.

I didn't have great results then so I enabled the framelimiter and manually changed the fps to match my refresh rate of 60.0 instead of 59.94 :

• Open PCSX2_vm.ini
• Change to "FramerateNTSC=60.00"

With that configuration, the input lag is realy reduced and the fps is smooth. I sometimes see really small tearings but it doesn't hinder the experience.

I am using RTSS with the settings you recommended, Scanline Sync -1, Framelimiter disabled, 60fps limit etc. The screen tearing is major (some people aren't as sensitive to it, but its constant on my end) making the small boost in responsiveness not worth the trade off, as well as not addressing the root issue, leaving me still to wait until this issue is patched.

I feel like something is being lost in translation across our posts. I appreciate your help in figuring out how to disable vsync, but the problem that I'm experiencing is there with or without vsync, whether the vsync is from pcsx2, RTSS, or disabled entirely.

It seems you either aren't experiencing the issue that has popped up for me and many others, or you just don't mind it, but pcsx2 at one point had about the same level of input lag as other emulators I've tried. It was only about a year ago that this major input lag problem occurred and has remained consistent since then.
I have used pcsx2 for years on both AMD and nvidia with great success, multiple different monitors, OS's, input devices, build versions etc. and never encountered this bug until a year ago, and it has not gone away since.

[Immersion95]

I'm sorry but it's impossible that you see tearings if PCSX2 Vsync is enabled.

Please disable the preset in the emulation tab and activate Standard Vsync.

For RTSS/Scanline Sync = You need to reduce the value to -30, -50 or even -100 to make the tearing line disappear. This hugely depends on your computer performance.

[phantomolecule]

I'm sorry but it's impossible that you see tearings if PCSX2 Vsync is enabled.

Please disable the preset in the emulation tab and activate Vsync.

I'm sorry but things are definitely getting lost in translation here. Please re-read my post, my issue is not with screen tearing, it is with input delay. I only mentioned screen tearing because you recommended I turn off vsync, but this has never been the issue I was chiming in about.

[Immersion95]

You were talking about trade off because the boost of input lag weren't worth the tearings. That's why I was suggesting ways to use Vsync to eliminate tearings while still having minimal input lag.

Regarding the "root" problem that you are dealing with, you are only talking about "feeling" I suppose.

• Have you done measurement with a 60fps camera to compare between the different emulators you are talking about ?

• Then, have you compared with the previous pcsx2 build that you used ?

  • How much frame of lags are we talking about ? Have you compared with the real console ?

I'm not denying your situation but please understand that the devs would need more precise information to investigate the matter.

[refractionpcsx2]

Can you guys try the PR #3785 ?

We changed some stuff which drastically improves frame times and the PR author felt that the input lag when playing GT4 was much better so could be worth trying it out.

[sonicfind]

Feels good to not have to hit notes so damn early in Gitaroo Man. Crazy.
Isn't perfect yet, but definitely better - at least in my case.

[Helium-4]

Definitely better than before, I've tested a bunch of games and felt an improvement on all of them.
Will test the latest change to see if there's any further improvement.

[refractionpcsx2]

Thanks @Helium-4 good to hear!

[ABU3BGE]

Can you guys try the PR #3785 ?

We changed some stuff which drastically improves frame times and the PR author felt that the input lag when playing GT4 was much better so could be worth trying it out.
I don't know what you mean do i need to change some settings or do I only update ?

[refractionpcsx2]

I don't know what you mean do i need to change some settings or do I only update ?

You just need to download the build at the bottom, where it says all checks passed click "show all checks" on the right then click "details" next to the windows build (second one down), then in the top right, click "Artifacts" and select the top download in that list. You can just extract the pcsx2.exe if you wish

[ABU3BGE]

I don't know what you mean do i need to change some settings or do I only update ?

You just need to download the build at the bottom, where it says all checks passed click "show all checks" on the right then click "details" next to the windows build (second one down), then in the top right, click "Artifacts" and select the top download in that list. You can just extract the pcsx2.exe if you wish

Thanks

[sandman332]

I tested 4 different games, honestly didn't really feel any difference in any of them.

[refractionpcsx2]

I tested 4 different games, honestly didn't really feel any difference in any of them.

That sucks :( A Few people now have noticed an improvement in the feel.

[ABU3BGE]

I tested shinobidu no improvement

[pokeshark]

as a benchmark, I used:

• Street Fighter Alpha3 from SF30th Anniversary Collection (Steam)
• Street Fighter Alpha3 from SFA Anthology

both games running at the same time with inputs shared. I recorded the screen doing basic actions in both games (neutral jumping, crouching medium kick..), then I frame stepped through the recording. it seemed in sync for most of the time, 1f of delay between instances at worst.

maybe this scenario could be used by someone more clever than me.

[refractionpcsx2]

That's some nice testing @pokeshark and good to know the lag for us isn't too dissimilar to the PC version :)

As for our recent changes, the input lag may not be any different but the perceived lag may be improved due to the improved frame time consistency

[refractionpcsx2]

@ABU3BGE @pokeshark @sandman332 @Helium-4 @Dogway

Can you guys test with this build (make sure you run this one) and see if input lag is improved, just trying something out to see if it's better, one guy on discord seems to think the input lag has gone, but I wanna be sure before I make any commits.

pcsx2-padupdate.zip

[Helium-4]

Can't feel any difference, tried measuring it and come up with either no difference or 1 frame difference either worse or better compared to v1.7.0-dev-520-gf60148979

[refractionpcsx2]

That's a shame, I've had 2 others say the input lag certainly seems lower, unless it depends on the game, I know some games have terrible input lag anyway and there's nothing we can do about that.

Would still like others to check.

[DeadManIV]

That's a shame, I've had 2 others say the input lag certainly seems lower, unless it depends on the game, I know some games have terrible input lag anyway and there's nothing we can do about that.

Would still like others to check.

Yeah I tried it with Jak 1 as well, can't feel any difference. The input lag is still really bad. Same with controller and keyboard. Seems like there's less input lag in the menus though. Moving around doesn't seem to result in input lag, it's just when you try to double jump or punch. Though I only played it for a a few minutes.

[refractionpcsx2]

And you're positive it doesn't feel like that on the console? I just don't wanna be chasing unicorns here.

[DeadManIV]

And you're positive it doesn't feel like that on the console? I just don't wanna be chasing unicorns here.

That's a good point. I might be able to test this out on my PS2, but I can't guarantee it unfortunately.
I did try the PS3 emulator to see what it was like there and the same issue is occurring... So maybe it is the game.

[DeadManIV]

And you're positive it doesn't feel like that on the console? I just don't wanna be chasing unicorns here.

I tried my Vita and my actual PS3. Seems to be about the same honestly... maybe I was just misremembering the game. Getting my PS2 out is much more annoying than getting my Vita/PS3 out. But I really want to know what the original was like. Maybe the game was just meant to have a sort of delayed double jump/ground pound.

Edit: and yet at the beginning of my Vita playthrough it seemed like the input lag was gone. But then it came back so I don't know. And I couldn't get it back the way it was after that.

[refractionpcsx2]

And you're positive it doesn't feel like that on the console? I just don't wanna be chasing unicorns here.

I tried my Vita and my actual PS3. Seems to be about the same honestly... maybe I was just misremembering the game. Getting my PS2 out is much more annoying than getting my Vita/PS3 out. But I really want to know what the original was like. Maybe the game was just meant to have a sort of delayed double jump/ground pound.

Edit: and yet at the beginning of my Vita playthrough it seemed like the input lag was gone. But then it came back so I don't know. And I couldn't get it back the way it was after that.

Well if it exists on those versions too, that's a mild relief, all the people saying PCSX2 is terrible, it's good to know the original games show the lag also. Emulators will always be worse by a frame or so, there's not much you can do about that.

Thank you for testing :)

[sandman332]

Sorry I'm just seeing these new posts now.

I tested same games as last time and felt no difference at all. Now, I did test this time with my PS2 going downstairs where my PS2 is hooked up and back to my computer with all but 1 game (disk is scratched always freezes now on PS2) and noticed that the input lag at least for the games I tested is not there on my actual PS2.

One game (well technically 2 games but the one is pretty much an expansion) was/still is absolutely unplayable on PCSX2 the input lag/delay is so godly bad but feels totally fine on my PS2. That game in particular is Delta Force: Black Hawk Down & Delta Force: Black Hawk Down – Team Sabre.

Other games tested are:
Need For Speed: Hot Pursuit 2
Battlefield 2 Modern Combat
James Bond 007: Nightfire
Ghost Recon 2

Again all the games still have some sort of input lag/delay and the FPS games are sadly brutal on PCSX2 compared to my PS2 especially when I tried aiming properly at someone hard to get an accurate direction with the delay there. Delta Force is definetly the worst of all of them on PCSX2 but for all games I really didn't notice any difference between the builds listed here in this thread.

Here's hoping one day this will be an issue of the past but for now, some of these games just aren't playable on PCSX2 (to me at least). The funniest thing of all is that I always thought for PCSX2 I would have had the issue of not having a strong enough PC to handle it, but nope, something like input lag is what killed it for me.

Keep up the great work guys it's still insanely impressive it's gotten this far just hope to see this pretty big issue hopefully either fixed or greatly improved somewhere down the line.

Thanks!

EDIT: Actually now that I think about it, has anybody checked how the input lag is on the Xbox Series X for emulating games? Scene it can be used to emulate lots of old games in dev mode, of course doing this you can't play normal Xbox X games then.

[refractionpcsx2]

@sandman332 thanks for replying, a couple of questions

1. Did you try the build I posted here on 2nd November?
2. Did you try configuring and using your keyboard to eliminate possible controller lag?

[sandman332]

Hi again,
Sorry really only have time on weekends lately to check stuff.

1. I did try that build you posted on 2nd of November (just deleted old .exe and replaced with the Nov. 2 one was that the correct way of checking it?) and didn't notice any difference.
2. I did not try configuring my keyboard will try that as well.

EDIT: I forgot to bring this up here (mentioned elsewhere) but something I did notice is that games that do support 60fps patches input lag/delay is practically non existent. I tested this with Hot Pursuit 2 and the input delay was completely gone, however I couldn't run the whole game at 60fps all the time but did test when the game was running fine and it was completely gone. Which makes me wish lots of the games I wanted to play had 60fps patches since it's pretty much gone from my test(s) however then there is the other issue where you need an even more powerful computer to run games with 60fps patches and if the game only runs normally in Software mode, pretty much out of luck getting a 60fps patch running there.

[refractionpcsx2]

well a 60fps patch won't change how we handle pad behaviour, PCSX2 will still do 60 vsyncs a second (even in 30fps mode) and this is when we check the pad for changes, the only thing your patch is changing is the game logic, so I don't know how that means it's our issue?

I'm not saying we don't have input lag, but you're changing stuff outside the emulation and it fixes the problem, if it was the emulator then it would still be an issue, but we're getting blamed for the problem, I just don't get the logic in that.

Edit: Okay admittedly PAL games will check 50 times a second, not 60, that was my bad, I was talking about games which are 30fps patched to 60. But aside from that, the logic is the same for every game.

[sandman332]

Sorry, I think it was just placebo. I only tested a 60fps patch with Hot Pursuit 2 at first, only a racing game so don't really need "precise" movement. Anyways I tried a 60fps patch with the worst game I have had input delay with (Black Hawk Down) and of course the game looked smoother and felt smoother it still definitely had quite bad input lag. The only difference being higher fps made it feel more smooth, but trying to aim properly and whatnot still shows the same results as without a 60fps patch. Same thing when using a 60fps patch on Ghost Recon 2, input lag is still bad (might be same as before) only difference is the 60 is making it feel more smooth but this can easily be seen when trying to aim at something/someone properly.

I'm still going to try and set up the keyboard at some point to see what results I get but not sure there will be any improvement.