precisazione importante sul funzionamento di GroovyMAME

[pucci]

purtroppo è in inglese, ma se qualcuno la vuol tradurre...ben venga!

What follows is only valid for GroovyMame starting from 12o. Older versions work slightly different. Regular Mame is another story (we've somewhat modified the way -syncrefresh, -waitvsync, -triplebuffer are implemented).

Well basically we try to calculate modelines with a refresh that matches the game's original fps. But that's not always possible, due to the usual limitations of monitors that can only sync at some ranges of hfreq. So, what actually determines which frequencies we can produce is the monitor type option we select mame.ini.

If you leave the default "cga" monitor, all 240 lines resolutions will be fine, but you won't be able to set a video mode of i.e. 400x256@60, it will only reach around 400@256@57. So for a game like 1942 that runs at 60 Hz, GroovyMame by default will disable sync to vertical retrace, and you'll have tearing.

We can force to sync to vertical retrace by enabling -syncrefresh. Inmediately, the game 1942 will reduce its speed to 95% (57/60). Scroll will be perfectly smooth. As sound is processed separately, it still thinks we are running at 100%, so periodically it will have to stop to let the game catch with the sound. In order to force sound to also sync with our rendering speed, we need to enable the -soundsync option. Obviously this only can be achieved by modifying its frequency by the same factor, so there will be a clear difference in pitch. But this is the only possible and less bad thing you can do if you really want have perfect scrolls without sound stuttering when your refresh doesn't match the game's fps.

If you really can't bear with the slow down or it's too bad for a particular game, then there's still a way you can have your game run at 100% without any tearing: the -triplebuffer option. As we'll run at the original speed, we don't need any sound trick here. Of course, there is a catch: tearing is removed as triplebuffer enables page flipping, but we won't have perfect scrolls any more, as the game action will not be synchronized with our vertical refresh. Page flipping however is still synchronized to vertical retrace, that's why tearing doesn't happen.

Depending on the game -triplebuffer method will be better than the other, so for pacman it's good as there's no scrolling and -syncrefresh would affect its speed badly, but for 1942 you'll notice the scroll has some small hiccups, which you can tolerate or not. Triplebuffering (as it's currently done in Mame/GroovyMame) has an additional drawback: it will add some input lag. However, this won't be so bad if you always use -multithreading (on by default). That's why for gameplay,-triplebuffer is less desirable than -syncrefresh.

If you enable -triplebuffer, then -syncrefresh is automatically disabled, so you if you enable both of them only -triplebuffer will be used. If you are going to use -triplebuffer for some game, it's a good idea to create an ini for it so you don't use that option all the time.

You may wonder what's -waitvsync used for now. In GroovyMame, -waitvsync is used internally by the program, so any value that you set to this option will be overriden. So, if you leave the options by default, -waitvsync will be enabled/disabled internally to perform synchronization when required. By enabling -syncrefresh, what you do is to tell GroovyMame to always force -waitvsync, whatever the refresh is. (Notice that in regular Mame, -syncrefresh/-waitvsync are exactly the same option, they do the same, as the mainstream code is implemented).

Now, back to the monitor type option, if you are positive your monitor accepts a wider range of frequencies than the default "cga" template, you can either choose some of the predefined monitors or create your custom settings that fit your particular monitor. There is a potencial risk to damage your monitor when messing with this stuff, it's never bad to remind this.

So, what I do is to choose my model: h9110. With this monitor, I have a way wider range than using the cga one, so I'll be able to generate i.e. 400x256@60Hz modeline, and thus run 1942 at 100% without forcing things. As you see, usually the monitor option is what most directly affects final game speed (if we want to sync to vertical retrace), and most issues with stuttering sound are produced by trying to sync to wrong refresh rates rather than needing more cpu power.

Finally, there some games that really are too much for our cpu: most 3D games for instance. The problem here is that usually, the right refresh is achieved, so GroovyMame will automatically enable -waitvsync. By doing this, our fps can be dramatically cut off by 50%, because most of our cpu time is wasted just waiting for vertical retrace. Again, the -triplebuffer option comes in handy here, as it will revert the -waitvsync mechanism and let the game engine run freely while our frames are flipped independently at the refresh speed. As GroovyMame has no way to guess if your cpu is going to be enough for a given game, -triplebuffer here needs to be added manually by you when required.

[pucci]

That said, tearing happens whenever you write to your video card memory out of the vblank period. The vblank is a brief gap of time before each frame is drawn.

So even if you were able to program your video card to refresh the screen at exact 60 Hz, and your cpu (mame) to throw frames at exact 60 Hz, you would have tearing *unless* you manage to make the blitting coincide with the vblank gaps between each frame.

In the real world, things are even more difficult, because you *can't* make your video card work at exact 60 Hz: it will run at 60.013 or something around.

So tearing should happen *always*, unless you use some sort of vertical synchronization. What we do is to wait for the exact moment where the vblank gap happens, and right then we fed our video card with the new frame. In GroovyMame, there are two implementations of this, that are somewhat different to the mainstream Mame ones (at least for ddraw):

- syncrefresh: synchronous vblank wait, videocard clock rules emulation speed (the game may run quicker/slower depending on the video mode)
- triplebuffer: asynchronous vblank wait, cpu clock rules emulation speed (the game may have scroll stuttering depending on the video mode)

[pucci]

if you're the lucky owner of a WG D9800, you'll virtually be able to have any single game perfectly synced at its native speed. This is not fully true as we are not usually able to get a 100% match of the original Hz with our modeline, we will always be some hundredths of Hz above or below, but that's not a problem cause GroovyMame will internally adjust the game speed to that so we won't notice, so for this reason GroovyMame is not the best Mame to look for tearing as it will hide it from us in most situations if our system is properly set up (right modelines installed).

However the problem appears if your monitor is not capable of covering the whole range of Hfreq and Vfreq that different Mame games require, actually what matters is the -monitor option you use in GroovyMame. Probably the easiest way to test this is to force Mame to only use PAL modes, that are restricted to 50Hz. As 50Hz is too far from 60Hz, GroovyMame won't try to sync and will let the game run at it's original speed (throttle).

- So use -monitor pal and the run a 60Hz game like wonderboy, you'll instantly notice the tearing.
- Now use the same settings but now add the -syncrefresh option: the speed should go down to 83%, scrool will be smooth, sound will stutter.
- Now add -soundsync option: you should have 83% speed, smooth scroll, smooth sound but lowered pitch.
- Now remove -syncrefresh and -soundsync and add -triplebuffer: speed will be 100%, sound will be perfect, scroll will stutter.

So this was a forced case but hopefully will help to explain other situations. Usually a standard arcade monitor will have a wider Vfreq range than the PAL standard so we should be able to sync to everything between 50-60Hz. The problem arises with vertical games rotated, that produce a resolution with too many lines: usually above 240 lines we won't be able to get a 60Hz modeline because our Hfreq would exceed the our monitor's limits. So in order to make an usuable modeline we have to lower its Vfreq to 58, 55, 50, etc. Hz. That's how we naturally get to the same situation we forced above. Typical cases are: dspirit, 1942, pacman, etc. For these games, you'll have to decide either: doing nothing (tearing), enabling -syncrefresh (lowered speed), enabling -triplebuffer (scroll stutter). Of course, it depends on the game one solution is better than the other.

Finally you have some vertical games that are just too tall when rotated so they can't be fixed by just lowering its speed. In those cases we "virtualize" (stretch+interlace). The bad thing about this is that we loose sharpness and detail. The nice thing is that, opposite to the previous case, we can match any Vfreq that we want by doing this, so "virtualized" games will run at perfect 100% without any other artifact. Typical cases are: donpachi, mazinger, etc.

[pucci]

For instance, Hantarex MTC 9110 (H9110) can go up to 16.7 KHz, so by choosing this monitor GroovyMame will be able to generate a 256 lines@60Hz modeline

ci saranno altri monitor "15khz" capaci di spingersi a 16,7khz come l'MTC 9110?

[pucci]

Calamity,

I'm confused. Why does he need to run VMMaker at all?

When I was using a generic ATI card with my Hantarex Polo 25, I just installed your custom ATI drivers and ran GroovyMAME with the default settings and it worked great for the games that I tried. I never ran VMMaker. Should I have?

Well, that's not really necessary, just convenient. If you use the default settings, generic CGA monitor timings are used, that means you are constrained to a narrower hfreq range around 15.7 kHz, what is fine for most games.

However, if you are possitive your monitor supports a wider range of hfreq then it's worth setting GroovyMAME so that it makes use of that extra horizontal frequency available. This is highly useful for running vertical games on horizontal monitor closer to their native vfreq.

For instance, 1942 won't run at 60 Hz with CGA settings. 256 are too many lines, it will only reach 58 Hz or so. However, if you use the H9110 settings, that game will be rendered at 16.6 kHz hfreq, so it will run at exact 60 Hz.

Anyway this can be selected from mame.ini, so why running VMMaker?

The reason is that the optimal video mode list is monitor dependent. In Windows, GroovyMAME can't create video modes on the fly, it (unfortunately) needs to rely on the list of modes available on the system. If we change the monitor type settings, GroovyMAME will be expecting a somewhat different mode list.

Although it can work just fine with the existing one most of the time (as well as using a fixed table as with the AVGA3000), it's a good idea to recalculate the mode list. This is specially true for "virtualized" resolutions.

Virtualized resolutions (interlaced + stretched) are used by vertical games which number of lines exceeds our monitor's capabilities. We need as much vertical resolution as our monitor can give us, so those resolutions are chosen by VMMaker/GroovyMAME depending on our monitor's definition.

Games like twincobr or donpachi, look incredibly better when using the H9110 settings on a monitor that supports that, than with the default settings, although you'd probably need to adjust your vertical amplitude potenciometer to get all the lines into the screen.

[pucci]

In VMMaker, monitor_specs lines only are read if you specify monitor type as CUSTOM. This is slightly different in GroovyMAME, where monitor_specs always override the values of the selected monitor.

[Exander]

Grazie mille, questo post è stato da vero utile, appena torno a casa stasera vedo se riesco a risolvere i miei problemi di shuttering.