[Patch] Core Emulation

Technical discussion for those interested in Supermodel development and Model 3 reverse engineering. Prospective contributors welcome.
Forum rules
Keep it classy!

  • No ROM requests or links.
  • Do not ask to be a play tester.
  • Do not ask about release dates.
  • No drama!

Re: [Patch] Core Emulation

Postby Ian » Sun Mar 19, 2017 3:29 pm

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
 
Posts: 879
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Core Emulation

Postby HarryTuttle » Mon Mar 20, 2017 3:40 am

Ian wrote: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.
User avatar
HarryTuttle
 
Posts: 320
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Core Emulation

Postby Ian » Mon Mar 20, 2017 5:00 am

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.
Ian
 
Posts: 879
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Core Emulation

Postby HarryTuttle » Mon Mar 20, 2017 5:23 am

Ian wrote: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).
User avatar
HarryTuttle
 
Posts: 320
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Core Emulation

Postby Ian » Mon Mar 20, 2017 7:30 am

Are you using a TV?
Ian
 
Posts: 879
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Core Emulation

Postby HarryTuttle » Mon Mar 20, 2017 9:21 am

Ian wrote:Are you using a TV?


No, I've got an Eizo ColorEdge monitor
User avatar
HarryTuttle
 
Posts: 320
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Core Emulation

Postby HarryTuttle » Wed Mar 22, 2017 3:27 pm

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?
User avatar
HarryTuttle
 
Posts: 320
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Core Emulation

Postby Ian » Wed Mar 22, 2017 3:41 pm

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
 
Posts: 879
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Core Emulation

Postby Ian » Wed Mar 22, 2017 3:50 pm

here's a graphic thing

Image

I'll draw what should happen
Ian
 
Posts: 879
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Core Emulation

Postby HarryTuttle » Wed Mar 22, 2017 3:59 pm

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.
User avatar
HarryTuttle
 
Posts: 320
Joined: Thu Mar 09, 2017 8:57 am

PreviousNext

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 2 guests