PCSX2 frame pacing is terrible.

[Aphexis]

Going to try the latest daily build from here, i'm using an EMUCR build i noticed, will get back to you guys.

[Aphexis]

Completely fixed with latest daily build.. issue is build dependant... issue closed

[Topken]

just part of the reason you should only get your builds from the official build bot instead of from other websites like emucr.

[jesalvein]

Closing this as it has been requested.
But next time :

i'm using an EMUCR build i noticed

please don't waste our time with unsupported builds
Thanks

[rama]

Hate to be that guy but..
PCSX2 does indeed have frame pacing problems. The biggest issue is that our internal frame limiter is a bit too lenient and that produces variable frame times.
On average, it'll be 60FPS. If you look at individual frame times, it is all over the place.
You can visualize the behaviour with FRAPS and a tool called FrafsBenchViewer. It looks like this:



On the plus side: It shouldn't be too hard to improve!
https://github.com/PCSX2/pcsx2/blob/6a7c...s.cpp#L389

@jesalvein: I hope you don't mind when I re-open this thread. It is useful if we keep it focused.

[jesalvein]

No problem since I only did it on request.
Nice to see you again on the forums BTW

[rama]

I'm always lurking but work means I can only take on smaller things. This here is perfect because I remember we abandoned this research for no particular reason and some work had been done already

So what the problem is basically:
When we're way too fast, we try to sleep the main thread for a pretty well determined amount. This is mostly fine.
But when we're just a little too fast, sleep is the wrong tool for the job. It is too imprecise and more often than not, we make the next frame too slow.
It works okay but it can't produce things like super smooth scrolling or perfect (no "bouncing") bob deinterlacing.

For a good demonstration of this, start up a Gran Tourismo 4 race, press start for pause and switch deinterlacing to Bob bff (with the limiter on).
You should notice occasional bouncing. It depends on your power saving settings in Windows and many other factors, btw.
Also it has to run well above 60FPS when unlimited (of course ).

Example scene:



Edit: Took out the Memory Card manager test and switched to GT4. It requires a demanding game to show the effect.

[Blyss Sarania]

I'm always lurking but work means I can only take on smaller things. This here is perfect because I remember we abandoned this research for no particular reason and some work had been done already

So what the problem is basically:
When we're way too fast, we try to sleep the main thread for a pretty well determined amount. This is mostly fine.
But when we're just a little too fast, sleep is the wrong tool for the job. It is too imprecise and more often than not, we make the next frame too slow.
It works okay but it can't produce things like super smooth scrolling or perfect (no "bouncing") bob deinterlacing.

For a good demonstration of this, start up a Gran Tourismo 4 race, press start for pause and switch deinterlacing to Bob bff (with the limiter on).
You should notice occasional bouncing. It depends on your power saving settings in Windows and many other factors, btw.
Also it has to run well above 60FPS unlimited (of course ).

Edit: Took out the Memory Card manager test and switched to GT4. It requires a demanding game to show the effect.

This is why I use busywaiting to time my NES emulator. As you say if you are only a little too fast then because of the resolution of sleep you will delay your thread too long. However busywaiting is of course not the best practice(Though it results in very good timing.) So in this case what can you do? I'm curious because I might do a similar thing XD

[Topken]

Its as I said the emulator is a little to imprecise causing some timing issues which makes things feel a little off at times

[gregory]

... I remember we abandoned this research for no particular reason...

Maybe the fact that people are busy and that we are counting on you