[Patch] Core Emulation

[Ian]

Harry, I want to push this timing fix. Unfortunately vs2013 only has low resolution timers, so I can't really test it. With your compile could you disable v sync on your pc then pause a game and see exactly what fps you get? With any luck it'll be almost bang on 60..

Forgot to say, use the high resolution clock

[HarryTuttle]

Harry, I want to push this timing fix. Unfortunately vs2013 only has low resolution timers, so I can't really test it. With your compile could you disable v sync on your pc then pause a game and see exactly what fps you get? With any luck it'll be almost bang on 60..

Forgot to say, use the high resolution clock

Ian, I've got almost steady 60fps. However not so often and for few instants it limits to 59.940056, that's exactly my monitor refresh rate (long story short: in native resolution it defaults to NTSC or 60/1001).

This makes me think of some sort of video syncing mechanism *beside* option's vsync (which I always disable btw). In fact I've never encountered the usual image tear effect in Supermodel, when in other emulators it's there due to even a subtle refresh rate difference between the game and the host machine.

That's why, I think, when option's vsync is enabled it tries to "double-sync" and produces of lot of stuttering.

[Ian]

You should always enable v-sync ;p
Since you run with v-sync disabled, surely you get higher than 60fps unthrottled?
The original supermodel throttle code, it looked like it was hitting 60fps, but what was actually happening was, for example
Frame 1 was drawn, frame 2 was drawn over the top, then only frame 2 was ever displayed
And then due to inaccuracies in the timing another emulated frame might be displayed twice, which resulted in significant judder

What I was attempting to due was a software v-sync. So each frame should be exactly 16.6 ms or whatever the internal is.
If you are only hitting 59.940056 maybe we need to tweak the code a bit.

[HarryTuttle]

You should always enable v-sync ;p
Since you run with v-sync disabled, surely you get higher than 60fps unthrottled?
...
What I was attempting to due was a software v-sync. So each frame should be exactly 16.6 ms or whatever the internal is.
If you are only hitting 59.940056 maybe we need to tweak the code a bit.

Actually I disable vsync 'cause of that stutter problem. When I run unthrottled it goes past 60fps but, and that's crazy, it always throttles when I pause.

As for that fps limit: it just switches from 60fps (hardcoded limit) and 59.94 (actual monitor refresh).

[Ian]

Are you using a TV?

[HarryTuttle]

Are you using a TV?

No, I've got an Eizo ColorEdge monitor

[HarryTuttle]

Ian, about the hi-res timer: to overcome vs2013 limitation, you could try MSYS2, just unpack in a folder (or get the installer) do a system update and you can compile with the included makefile (my modified one works great also).

Or you can use a preprocessor directive in <Main.cpp> to change the timer at compile-time, low-res for vs2013 and high-res for mingw. What do you think?

[Ian]

I wrote this

Code: Select all

UINT64 GetSuperTime()
{
   LARGE_INTEGER time;
   QueryPerformanceCounter(&time);

   return (time.QuadPart * 1000000) / frequency.QuadPart;
}

static void SuperSleep(LONGLONG time)
{
   auto start = GetSuperTime();
   auto tics = start;

   while (start + time > tics) {
      tics = GetSuperTime();
   }
}

I get bang on 60fps with it. But the trouble is .. we are drawing a frame, then 'sleeping' or really spinning until 16.6ms is over. But that means that the actual SwapBuffers command could in theory be called at any point in the 16.6ms time frame. If that varies between frames you'll find with vsync disabled you will again show some frames twice, and other frames will be overwritten before they are displayed. I'll draw a pic to better clarify

[Ian]

here's a graphic thing



I'll draw what should happen

[HarryTuttle]

Dunno if this means rewriting the emulator, but could a solution like MAME be useful in this context ? I mean, MAME has a "machine time" that you can alter so to execute a game at half-speed, double, or any arbitrary multiplier.

If we take as a reference the host machine screen refresh rate we could compare it to the emulated machine and speedup or slowdown it proportionally.

In my personal MAME build, for example, i modified the code to adapt to host screen refresh rate in both direction (MAME only slows down), so I always have rock solid fluid game speed v-synced to my monitor. That means obviously I'll play slightly accelerated or slowed down games, but until the difference is lower than say 4-5 fps, it's still good (at least for me).

It could be a third, albeit non optimal, way to the usual Screen-Tearaing vs Stutter, until G-Sync/Free-Sync monitor will be common hardware.