Thanks for the nice comments.
I assume different frame_delay settings may sometimes be required for different games, with some being more demanding than others. Is it possible to create an "auto" setting? It could start at 9, then back off incrementally if it detects that it is regularly skipping frames. This would save the work of carefully determining a frame_delay setting for each game.
Is this a possibility?
You're certainly right that different games may need different frame_delay settings, it all depends on how demanding each game is.
I'll let Calamity judge whether or not he would think it would be feasible to create some sort of auto setting, but to manage some expectations, personally I don't think that will be as easy as it may sound.
Let's talk about the reliability of emulation at frame_delay of 9. Pressing F11 gets you the operational competency of the emulation / computer you're running the emulation on (correct me if I'm wrong.) I don't get any "Skips" but the emulation does dip down below 100% on the more challenging (SH-3-based) games very frequently. Is this problematic from an accuracy standpoint?
This is with an i7 3770k.
Jim, yes dipping below 100% is problematic from an accuracy standpoint. The game should run at 100% at all time, no dipping allowed except for maybe shortly at startup. Otherwise something is definitely wrong.
Just one important point up front. The frame_delay in current public GM is sort of broken. Calamity found a way to improve it and has made a patch for that, which will be in the next update if I'm right. In my tests I've been using a manual patch that I applied myself to the source. I'm not sure that it'll make your example any different, but just that you know.
As replied to rCadeGaming, different games put different demands on the host hardware, resulting in one game being more demanding than others. What "more demanding" really means is that it needs longer to emulate a frame than a less demanding game does. Of course the longer it takes to emulate a frame, the lower the frame_delay value can be (otherwise you'll be pushing the frame emulation too far that it hasn't finished emulating the current frame before vblank comes), and vice versa, the less demanding the game the higher the frame_delay can be.
What's important to understand is that you know your way around testing how demanding a game is. That's actually quite simple: run the game you want to test unthrottled and it will tell you what speed it can achieve. You do this by running it once with the -nothrottle option from command shell. You also add "-v" such that it will output some stats at exit. After that it's simple math.
So as an example, if I run outrun in MAME ("mame.exe outrun -nothrottle -v", let it run for some 30 seconds then quit, then on my machine it shows that it's able to run at 792% unthrottled . So for simplicitly I'll round this to 800%, or said differently 8 times as fast as the original hardware.
Now outrun originally runs at 60hz (and something), i.e. 60 fps. Dividing 1/60 gives us 0,016667 seconds per frame, which multiplied times 1000 says each frame is taking 16.67 milliseconds. Since mame runs it 8 times faster on average
, it means on average
a frame in mame takes 16.67/8=2.08 milliseconds. I'm stressing the "on average", as emulation is mostly not about averages: some frames may take longer to emulate than others. As a rule of thumb
you may multiply the average frame emulate time by 2, i.e. the toughest frames to emulate take twice the average. So that brings us to 2 times 2.08 = 4.16 milliseconds that we at least need in each frame left to emulate the frame and still be in time for vblank.
So how large can frame_delay then be? Each frame takes 16.67ms of which 4.16ms need to be left for emulation. So 16.67ms - 4.16ms = 12.51ms is the maximum value at which we need to start the emulation. Now, frame_delay goes in steps of 1/10th a frame (with maximum setting 9). So in this case each higher value from 0 is adding 16.67/10 = 1.67ms. The largest value for frame_delay that may be used is thus 12.51ms/1.67ms = 7(.47). So I could use a frame_delay of 7 for outrun on my machine (a 4.6Ghz 3770K) , going any higher to 8 or even 9 , would most surely lead to some (or a lot) emulated frames not being finished in time anymore for vblank, and thus skipped frames / loss of emulation accuracy / input latency added.
Of course you can try to play a little bit with the frame_delay values, but deviating from the calculated value above is more likely to get you in trouble then not. Of course you should also always keep in mind that some drivers / games may be demanding in way that makes the time to emulate different frames go all over the place, such that the average speed it runs at won't be helping you.
So, as above example shows, you'll not be able to run all drivers at a frame_delay of 9. But at least you now may have an idea how to calculate what a good value can be. Of course trial and error would in the end bring you to round about the same value. Expect most to be in the range of safe values of say 5-7, with only the drivers that run -really- fast that can be set to reliably run with a frame_delay of 8 or 9. And of course not forgetting the fact that some real demanding games / drivers may not even go higher than a value of 1 or 2. In my testing I used for example a driver that runs unthrottled at 2600%, or 26 times as fast as the original. Now do the maths and you'll see that's a candidate to run at a value of 9
i'd be interested to know opinions of the reliability of overclocking usb ports to 1ms (1000hz) .. ie. is there any risk to your hardware or performance issues etc?
below: from Raziel's UsbRate v0.5:
For as far as I know there's no real risk to your hardware. If you notice some erratic behaviour then you can always uninstall the USB rate overclock and set it back to normal. From what I read on some hardware it may show that erratic behaviour, but I personally never had any issues with it. Do note that I have no experience with the tool you're quoting, I've been using the USB overclock mentioned elsewhere in this thread.