Right settings for Groovymame

[Monkee]

Hi, I've seen a lot of people (on a french forum I follow) setting vsync and -syncrefresh to 0 and using throttle instead.

Now I'm confused, what's the right settings for Groovymame (on a CRT of course) to perform properly?

[Calamity]

The thing is -throttle and -syncrefresh are NOT mutually exclusive. Indeed, you *need* throttle enabled otherwise syncrefresh won't be considered.

That said, since SwitchRes 14, the behaviour is this:

- Automatic syncrefresh/triplebuffer selection. If you leave both options disabled in mame.ini, GroovyMAME will decide which one to use automatically. If the target refresh is achieved, GroovyMAME will select -syncrefresh. On the other hand, if we cannot achieve the desired refresh, due to monitor limitations, triplebuffer is used instead, so that speed is kept at 100% rennouncing to smooth scrolling. You can control how off the obtained refresh must be in order to trigger triplebuffering, by means of the new option -sync_refresh_tolerance. The default value is 2 Hz.

When -syncrefresh and -triplebuffer are left disabled in mame.ini, this allows GroovyMAME to use them automatically. Forcing any of them enabled, obviously prevents GroovyMAME from deciding, so it's not the recommended default setting unless you have a good reason.

So, yes, your French folks are right after all.

[Monkee]

Thanks Calamity. What about the "waitvsync" and "synch to monitor refresh" though, should I let them on 0 too?

[machyavel]

Thanks Calamity. What about the "waitvsync" and "synch to monitor refresh" though, should I let them on 0 too?

Hello All,

Monkee, I think I've read these kind of "official mame" options are being ignored by groovymame.

Calamity, may I ask your comments regarding the attached chart? What I did was running rtype with:
sync_refresh_tolerance 9.0, <- so I'm sure it applies to rtype (~55 Hz) when displayed on my lcd (60 Hz)
syncrefresh 0,
throttle 0,
triplebuffer 0,
frame_delay 0,
multithreading 0,
into mame.ini and lauching command-line with desired options (-nosrf/-srf, -frame_delay 0/-frame_delay 9, -nomt/-mt).
The result is the % shown by pressing F11, either throttled or unthrottled.

To me it looks likes:
- throttling is always on when srf is on + everything else is off,
- frame_delay works only when srf is on has there's an impact on performance only with srf on.

[Calamity]

Hi machyavel,

Please can you confirm the third row? I find it strange that you get exactly 100% with throttle on in there.

[machyavel]

Calamity,

I made raw 3 again and attached the log (100% reported)

Now I have to mention I made the test reported to the chart above always using -nothrottle and then applying F10 ingame. For re-test of raw 3 and raw 7 I used command line option -throttle instead.

I'm telling this because I noticed re-testing raw 7 this way, the log now reads 100%, which is not consistent with the chart. However, it's not the same 100% as raw 3 because in this case F11 shows alternatively 96/101%, while raw 3 shows 100% ingame.

[Calamity]

To me it looks likes:
- throttling is always on when srf is on + everything else is off,

It's not exactly that. The explanation for row 5 is that even with throttle off, GM can't bypass the wait for vsync because it is running in a single thread. To make things perfect, GM should also bypass the wait for vsync in that situation (throttle off) and be free to run full speed, but that only happens if you enable multithreading.

- frame_delay works only when srf is on has there's an impact on performance only with srf on.

This is absolutely true. In the video_manager::update_throttle method:

if (m_framedelay != 0 && m_framedelay < 10 && m_syncrefresh && mode->hactive)
[...]

[machyavel]

Thanks a lot for the explanation!

By the way, I noticed when frame_delay is active, a few lines seem to leap/stutter slightly offset. Is it known side-effect?

ps: regarding the raw 7 inconsistency, I found it falls back to 72% when cycling F10 while the throttle is activated through CLI. I'm then tempted to think throttling should always be actived/confirmed through UI.