MAME v-sync/refresh/speed-up question

[Ed Oscuro]

You are going to get different answers for different questions. "What is most accurate" is different from "what meets my needs," which is the main point I'm making.

Thanks for linking Calamity's post, which answers a question I asked recently (either having skimmed Calamity's post, or having forgotten what was written):

On the other hand, we have the input lag issue. Since long I have read that any sort of v-sync causes input lag to some extent. Because of this, it is widely recommended to disable v-sync or triplebuffering as a way to reduce input lag. However, once you get used to properly v-synced video, you simply can't go back and live with the artifacts, it just kills the illusion of emulation altogether.

So I tried to understand why v-sync shoud introduce input lag at all. And specially, why should it add more lag than using -throttle alone ???. After all, they're basically just two different implementations of a wait loop to keep the frame rate in place. Most articles I've read assume the modern 3D-game scenario, where frame rates are not constant. In emulation, the frame rate is a known value.

To keep short, I found what could be the possible cause of input lag related to v-sync in MAME. Basically, MAME is locked to input messages from the OS for the period of time which takes a new frame to be drawn to the screen. This is because the draw operation is called from the message loop where the input messages are supposed to be processed too. Obviously, if v-sync is enabled, the draw operation won't return until the vblank happens, consuming most of the time in the frame and keeping the message loop locked.

This suggests a question: Can you actually get accurate behavior from the game if you don't lock the inputs for the whole duration of the frame? Seems to me that at some point most any arcade game is going to lock the internal game state, and either buffer or ignore continued inputs. There is not a game state update happening every scanline - not even close!

[Fudoh]

Should we read the 104% speed as something really affecting the game's normal speed or is this a misleading fgure ?

as long as we have to deal with displays with fixed refresh rates, it's a neccessary evil. Speeding up (or slowing down in rare instances) a game to match your monitor's refresh rate is the only way to get smooth scrolling without tearing on your standard LCD display.

Running DDP, R-Type or Raiden at 104% definitely makes the games a little harder, but if I have to decide between that and massive video problems, it's always the increased speed for me. Same for conversions like Raiden Fighters on the 360. There you get various options (including a frame blending at 54Hz), but I still prefer the ultra-smooth 60Hz with a little speed up.

[Xyga]

Thanks to both of you for your replies.

Now if I understand; what RetroArch is trying to do is to take both the game's and the display's values and bring them as close as possible together to minimize tearing ?

If that's it, then should we understand this method as some kind of compromise ?

[Ed Oscuro]

That's a great point. If there is a general rule of thumb, it's probably going to be that games with movement perpendicular to the scanlines will have bad tearing (i.e., vertical games with the background scrolling down the screen) where you might decide you want v-sync (I still avoid it there usually, tearing could cause bullets to be lost, along with other details that simply fall between the partial updates). Games with movement paralel to the scanlines probably won't be harmed as much by tearing.

[Xyga]

Well I yet to try all this stuff, but someone told me today that with that RetroArch method, a little tearing is visible in d3d mode, but it's completely gone in Ogl mode (at the cost of monstrous cpu time).

What's bugging me is that his counter was still showing 104% no matter what... so is this a compromise, or an illusion ?

[fagin]

Have they managed to fix sound skipping issues when game refresh rates are being butchered?

At times, emulation of PCB's is just so broken in MAME compared to the real deal (PCB's) on CRT's.

I suspect it's pretty much like the saying "Once you've had black you'll never go back". Mmmmm.... not quite sure that's the right analogy.

[Xyga]

Supposedly the 'compromise' used in RetroArch makes use of the sound data synced together with video and therefore shouldn't butcher sound...

*scratching head*

[fagin]

It would be good to hear from others experience, as the sound gimping and also increased lag of all this butchering, just sounds a problem with syncs that are far out if the 60hz spec.

[matrigs]

EDIT 3:

So, i played a bit with those settings in the latest shmupmame 4 (after again losing my patience with groovymame) and i got some stuff to share.

Basically, i am trying to have a perfect scrolling picture on my Naomi VGA CRT screen. I am testing this with Dodonpachi as it clearly shows the 104% @ 60 Hz indicating that it syncs right.

When using Direct 3D it's enough to have multithreading off, throttle off and syncrefresh on to have it play stable at 104% @ 60 Hz. I then added a 640x480 @ 57.77 HZ modeline with soft 15 khz and i got a perfectly scrolling Dodonpachi at 100% @ 57.55 Hz.

Now - for some reason i cannot really achieve perfect linedoubling with Direct 3D as it always adds some weird scaling and stretching which i cannot get rid off, so i am trying to use DDraw.

DDraw requires triple buffering to be switched on, as otherwise with throttling off the game plays at super speed. Still, with all the correct settings the speed percentage meter at the top of the screen would wildly alternate between 98% and 104% so i was convinced that it doesn't work.

I was wrong, as i counted the frames needed for the boot up text, and it needs the same amount of frames as the game running in Direct 3D in perfect 100% speed. So it workds in DDraw, but is just incorrectly indicated.

Looks pretty damn amazing now.

[haynor666]

matrigs, you could try any mame with soundsync and cleanstretch patches applied (both originally from cabmame). Both patches solves my problems with sound stuttering and artefacts from stretching with d3d. Doesn't matter if you are using arcade monitor/TV or LCD monitor.