After three months of coding and testing, GroovyMAME is back with SwitchRes Patch version 0.014, which we hope will be a big step forward in terms of functionality, based on the feedback of hundreds of users. Most of the code has been rewritten for this version, in an effort to build a cross-platform stable model which can eventually receive a proper documentation.

GroovyMAME is a custom M.A.M.E. build mainly aimed at CRT monitors, as we are convinced CRT technology is a must when it comes to enjoying emulation in its full glory. However you can use GroovyMAME to alliviate some of the annoyances associated to emulation on LCD displays, specially for those models which are capable of refreshing at custom rates.

While the improved synchronization feature is system independent, you are going to need a special hardware and software setup in order to get the full potential out of GroovyMAME.

As for the hardware part, do yourself a favour and grab an old ATI Radeon card, any model from Radeon 7000 to the HD 4xxx family should work, both AGP and PCIe models. As far as we know, there is nothing that can remotely compare to these cards in terms of flexibility.

On the software side of things, you need to be aware that operating systems are not designed to deal with hundreds of video modes as we are going to need here, so some degree of hacking is required. You can use one of these two options:

Either one of these operating systems combined with one supported ATI card is the preferred environment to run GroovyMAME in. However, since SwitchRes v0.014, GroovyMAME can also generate custom timings under Windows for virtually any card supported by PowerStrip, by making use of its API. In theory, this should work for Windows 7 too. Anyway, keep in mind that this method is way more limited and unreliable than the standard one.

There are many changes and things that will need a detailed explanation, so I will keep updating this during the following weeks.

GroovyMAME can get all your resolutions to almost fit perfectly on the HORIZONTAL, once you find your custom specs. No software can control the VERTICAL size of a resolution on a CRT monitor, you need to adjust it physically (potentiometers, service menu, etc.).

- First version with native Windows 7 support, getting things ready for the advent of CRT Emudriver for Windows 7.- Workaround for progressive/interlaced mode switching in Windows 7 and DirectDraw. - Changed DirectDraw to use flipping surfaces with -waitvsync too, to allow bilinear filtering in Windows 7. Also fixes the problem of -waitvsync resulting in double speed in Windows 7. However, it may cause tearing on LCD displays when using DirectDraw, so make sure to use Direct3D with LCD monitors.- Fixed crash on exit for 32-bit builds on Windows 7.

What's new in SwitchRes v0.014a

- Fixed bug that made some games appear mirrored or upside-down.- Fixed incorrect monitor presets: ms2930, k7000- Added two new settings for the -orientation option: rotate_r, rotate_l. Use either one of those in case you have a vertically mounted monitor so to specify its correct rotation direction.- Improved filtering of system resolutions to avoid triplicated enumeration in some systems.- Now the GroovyMAME version is prompted after the main version so we no longer create conflicts with frontends which grab the version of MAME from the credits text.

What's new in SwitchRes v0.014

- Fully rewritten modeline engine. Redesigned algorithm for resolution picking, now each resolution reported by the system is evaluated individually according to your monitor specs.

- Full PowerStrip integration, so at least in theory many more cards are now supported (i.e NVidia).

- Support for VESA generalized timing formula (GTF), this is to provide quick support for multisync PC CRT monitors (not for the ancient fixed-frequency ones!). Use the monitor presets labeled as "vesa".

Note: labels are no longer case sensitive- New format for defining custom monitor specs, now the -crt_range0-9 options are used. This is the most important change in this version from the user's point of view, as the existing custom definitions will need to be modified. Not big deal however, but make sure you understand how this works as it will guarantee your success with GroovyMAME. The usual timing values remain the same, but the line limiters are replaced by four values: ProgressiveLinesMin, ProgressiveLinesMax, InterlacedLinesMin, InterlacedLinesMax. These are used to easily define the upper and lower limits of the total logical resolutions GroovyMAME should allow, both for the progressive and the interlaced range. You may leave either one of the two ranges set as zero in case you do not want progressive or interlaced modes to be generated. So the current format is as follows:

-crt_range 0-9HfreqMin-HfreqMax, VfreqMin-VfreqMax, HFrontPorch, HSyncPulse, HBackPorch, VfrontPorch, VSyncPulse, VBackPorch, HSyncPol, VSyncPol, ProgressiveLinesMin, ProgressiveLinesMax, InterlacedLinesMin, InterlacedLinesMax- Automatic LCD timings generation. This is useful in combination with PowerStrip. Your current timings will be read from PowerStrip and used to recalculate modelines from them. You just need to define the range for the vertical refresh your monitor supports:

-lcd_range VfreqMin-VfreqMax- Improved rotation detection, now you can rotate the screen from the internal UI and the video mode will be recalculated properly.

- New priority system for option setting. GroovyMAME will set most of its required options automatically (-syncrefresh, -triplebuffer, -resolution, etc.), overriding the values in mame.ini. However, any other ini you create (rom, driver, orientation, etc.), as well as command line settings, will have higher priority than GroovyMAME's option setting, so you can always force something different if you feel GroovyMAME is not doing things right.

- Resolution forcing. As opposite to previous versions, now you can force the resolution that GroovyMAME picks. GroovyMAME will do its best to acommodate the game's resolution into the one you suggest.

- 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.

- Frequency scaling. Now GroovyMAME can use a multiple of the target vertical refresh if allowed by the monitor. This can be used in combination with PC CRT monitors which allow frequencies of 120 Hz, in order to achieve low resolution modes with true hardware scanlines. You need to create a custom crt_range for this. By now, -triplebuffer is used automatically for this mode. However, in order to achieve perfect scrolling you will need to use -syncrefresh in combination with -frame_delay 5, provided your system can deal with it.

- Interlace/doublescan modes can now be effectively disabled by means of their respective options. Be aware that SwitchRes does not support doublescan modes in Windows.

- Positive/negative sync polarity support under Windows.

- New option -lock_system_modes for mode filtering. In order to limit the possibility of selecting a potentially dangerous mode, the new option -lock_system_modes will prevent any mode not created by us from being picked. This will enforce GroovyMAME to use custom modes previously generated by CRT_EmuDriver. For non-ATI cards this option will block all modes actually since none of them is recognized as custom. This is the case of NVidia cards in combination with PowerStrip, or the ArcadeVGA 3000, where its custom modes are actually reported by the system as standard modes. So for these cases you should disable this option.

- New option -lock_unsupported_modes. You should only disable this option if you are possitive your system, based on your monitor's EDID, is filtering some modes that you actually created. Otherwise leave it enabled. This option only has effect in combination with -video ddraw.

- New option -refresh_dont_care. The new algorithm will filter resolutions that are out of your monitor specs. Old versions of the ArcadeVGA, as well as the Soft-15kHz program, label all resolutions as 60 Hz. This means that if this value were to be taken seriously, resolutions above 240 lines would be out of range for most arcade monitors. This option is provided in order to cope with this peculiarity, and it basically tells the algorithm to ignore refresh for range checking.

- New option -frame_delay. Delays the start of the emulation of each frame by an amount of time defined in tenths of the frame period length (0-9), in order to give a chance to the emulator to have the most possible updated input for that frame, as an attempt to minimize input lag. A value of 0 corresponds to standard behaviour. This option is experimental, and is known to produce tearing in LCD screens.

For those of you willing to try the new version, some important notes:

- Make sure to create a fresh mame.ini (most options have changed so this is required!!)- Make sure to regenerate your video modes with VMMaker in the first place, this is specially important if you've been using magic resolutions with previous versions of GM, as some junk modelines be have been stored as a result of GM unproperly exiting that will fool the new version.- Make sure to update your own custom -monitor_specs lines to the new -crt_range format, notice that even the name of the option is different in order to avoid confusions.

Superb release, thank you very much!! It's working wonderfully well on my setup, smooth scrolling and the input response is great!

While doing some first tests with the new frame_delay feature, I also found something interesting that fixes the issue with the <240 line modes running way too fast on my setup (win7+soft15khz), as we spoke about some time ago (see: http://forum.arcadecontrols.com/index.php/topic,120331.msg1313434.html#msg1313434). That speed issue for those specific screenmodes is completely fixed now when I set the frame_delay parameter to 1 (or higher)!

I have attached more detailed logs in case you are interested. The test was done with the "genesis.ini" settings, -only- changing the "frame_delay" from 0 to 1 in the two testcases. At a setting of frame_delay=0 the speed is much too high (179%), just as we discussed about in the other thread, but with the setting of frame_delay=1 the issue is completely fixed and everything is running smoothly at the correct speed.

Not sure what's causing it to run too fast for those specific screenmodes with the frame_delay at 0, but I'm a happy man now, because I guess I would and will run most emulation with a frame_delay setting of 1 or higher already by default..

I think the issues related to vector games are solved, I used the list you provided for testing, anyway let me know if you still experience any problem. I considered to add your options for vector games, but I found that the default look of vectors varies depending on the api used (ddraw/d3d/sdl) so I thought I'd better leave the user decide.

While doing some first tests with the new frame_delay feature, I also found something interesting that fixes the issue with the <240 line modes running way too fast on my setup (win7+soft15khz), as we spoke about some time ago (see: http://forum.arcadecontrols.com/index.php/topic,120331.msg1313434.html#msg1313434). That speed issue for those specific screenmodes is completely fixed now when I set the frame_delay parameter to 1 (or higher)!

Hi Dr.Venom, I'll continue with the discusion we had pending in your thread. Just wanted to add that obviously the highest the value of -frame_delay you use while still getting stable results for a particular game, the better for performance.

Nice, going to check it out.So in mame ini I just select the ms2930 settings as my monitor and in vmmaker I still add the timings of the 2931 right?

This is a general warning: VMMaker is not yet up to date with the new monitor specs format (-crt_range), so for vmmaker.ini use the previous timings that were working for you in order to create the modes and then select the right new settings in mame.ini. Hopefully I can update VMMaker soon, it's my #1 priority now.

Hi Calamity, I noticed that when using GroovyUME under the TAB menu it still doesn't give the option to 'Input (This System)' which means I can't have different buttons set for MAME and SNES without doing it for each game. Do you know if there is a work around for this?

Fantastic work! Looks like there's lots of new stuff to play around with

One question though, is there a way to stop it sounding like a wonkey record when the CPU can't keep up? For instance Tekken Tag does lag a little bit on my system but still perfectly playable, though it now sounds awful whereas before it just skipped a bit now and then.

Is this soundsync doing it's thing? I didn't see an option to disable it.

One question though, is there a way to stop it sounding like a wonkey record when the CPU can't keep up? For instance Tekken Tag does lag a little bit on my system but still perfectly playable, though it now sounds awful whereas before it just skipped a bit now and then.

Is this soundsync doing it's thing? I didn't see an option to disable it.

When -syncrefresh is enabled, sound is also tied to that so there's no need for a -soundsync option. Try forcing -triplebuffer for those problematic games, that will release the sound too.

I think the issues related to vector games are solved, I used the list you provided for testing, anyway let me know if you still experience any problem. I considered to add your options for vector games, but I found that the default look of vectors varies depending on the api used (ddraw/d3d/sdl) so I thought I'd better leave the user decide.

Thanks. I can't wait to try it out when I get some free time. I'm sure I speak for everyone here when I say that we appreciate all your hard work.

I tried to run GroovyMAME 147, and Im having slowdowns on all games, regardless of the actual amount of resources they need.

I created a new mame.ini as instructed, and used the generic 15k preset for testing.

I used the 64bit version available on the google code site.

The CPU is an Athlon XP 64 3200+ or something like that, running 64bit Windows. I know Its not the ideal CPU for MAME, but the same games that now have slowdowns ran perfectly with 146 (both the generic 64 and 32bit versions available on the site, and the one compiled by me with Athlon 64 optimisation flags.)

So is it a resource usage issue, or should I look up into something else?

I tried to run GroovyMAME 147, and Im having slowdowns on all games, regardless of the actual amount of resources they need.

All games? Or just a few of them? Vertical games? Slowdowns can be either CPU related, or refresh rate related (check your monitor settings, generic_15 is very conservative, try arcade_15). Try disabling -syncrefresh from command-line to find the answer, or... go into Game Information and check if the game is running at its native refresh or if it's been reduced to meet your monitor specs,

Can you please check my settings for an ArcadeVGA 3000 type setup. I think I got it right now. Before I would never have to touch the ini so I am just making sure.

Yes, those would be the right settings for the 3000. If you have the chance, please attach a log here so I can see how the modes are being reported by the system and guess if there's some potential problem (I don't have one here to test that's why I'm asking).

Why would someone want to do that? Well, there are some 100 Hz TVs with built-in de-interlacing that do a good job with interlaced sources, but look like crap with progressive video. I remind one user here having this issue, and at the time there was no straight-forward solution, now this should do the trick while still preserving the native refresh rate.

Yes, those would be the right settings for the 3000. If you have the chance, please attach a log here so I can see how the modes are being reported by the system and guess if there's some potential problem (I don't have one here to test that's why I'm asking).

As requested. See attached. I am giving you two examples, one that works and one that does not.

Mspacman looks like it is not syncing with the monitor. It just scrolls a lot.

One thing I forgot to mention is that this latest version of GroovyMAME makes the QMC2 front-end (http://qmc2.arcadehits.net/wordpress/) to hang during initialization. It's because the front-end looks for the MAME/UME version number in the exe and can't find it in the expected place, because the GroovyMAME Switchres version information is there:

As requested. See attached. I am giving you two examples, one that works and one that does not.

Mspacman looks like it is not syncing with the monitor. It just scrolls a lot.

Hi cack01, thanks for your logs.

I've noticed several things:

- For some reason you're using the '-monitor vertical' option for mspacman. I guess this is intended, because you are physically rotating your monitor. Otherwise you should leave it as 'horizontal'.

- I didn't notice before that you have the -modeline option disabled. This is not right, the -modeline option should always be enabled even if your modes are not editable (as is the case with Arcade VGA 3000). This is so because the pick-best-mode routine and the modeline generation routine are the same one, so all the logic is bypassed when disabling this option. This logic is responsible of setting the right options afterwards, including the rotation and scaling options.

- So GM believes you're running a Tate setup, but as the -modeline option is disabled, its pick-best-mode routine is being bypassed and MAME's default algorithm is being used instead, which is not aware that you're intending to run tated so its picking the 352x288 resolution. Then the -changeres option notices the screen size is not 288x224 and interprets it as a resolution change, and this creates a fatal loop. So this is a definitely a flaw of the current design, but I think the only sensible way out is add some code that automatically disables the -changeres functionality in case the -modeline option is not used.

- Finally, contrary to my belief, the ArcadeVGA 3000 is reporting some modes with their right refresh (400x256@53) but the rest of them are labeled as 59 Hz, even in cases when this is certainly not true (352x288@59 would be 18 kHz), so definitely the -refresh_dont_care option must be used here too.

One thing I forgot to mention is that this latest version of GroovyMAME makes the QMC2 front-end (http://qmc2.arcadehits.net/wordpress/) to hang during initialization. It's because the front-end looks for the MAME/UME version number in the exe and can't find it in the expected place, because the GroovyMAME Switchres version information is there:

Thanks for reporting this Dr.Venom. This will need to get fixed on the next update. Anyway, that's too bad about QMC2, that's not an ortodox way of retrieving the version of MAME if you ask me, they should be using the XML information instead.

- For some reason you're using the '-monitor vertical' option for mspacman. I guess this is intended, because you are physically rotating your monitor. Otherwise you should leave it as 'horizontal'.

.............................................

Thanks for the help. Changed modeline and -refresh don't care to "on" and everything looks great.

No idea on mspacman being set to vertical. I do not even have an ini for any games setup. maybe a default option for the driver/game? Works fine after the above changes though. Actually all my verticle games were having issues until I made your changes.

So I've been doing some tests these days, and the new option named -frame_delay is going to be ready for the next release. I've done it so that a frame time is divided in 10 parts, so a frame_delay value of 0 (default) means the emulation starts at the beginning of the frame time, as always.

I had been using Soft15kHz + Powerstrip in XP64 with a Geforce 7300GS PCI-e card to work with native resolutions with DirectDraw in vanilla MAME. Actually, I have three of them, because I plan on making at least two cabs and I found a great deal on eBay. Will these work with GroovyMAME or do I need to get some Radeon cards? I noticed this when looking into GroovyMAME:

As for the hardware part, do yourself a favour and grab an old ATI Radeon card, any model from Radeon 7000 to the HD 4xxx family should work, both AGP and PCIe models. As far as we know, there is nothing that can remotely compare to these cards in terms of flexibility.

I'm not too familiar with GroovyMAME yet. Would the Geforce card even work, or do I need something running the Catalyst drivers? If it would work, would it be less flexible for timing adjustments than the Radeon? It's worked fairly well so far. How would I check if a Radeon card could be better?

I'm not unwilling to go ahead and pay for some more video cards if I'll get better results, but I just want to make sure if I will or not.

I'm not too familiar with GroovyMAME yet. Would the Geforce card even work, or do I need something running the Catalyst drivers? If it would work, would it be less flexible for timing adjustments than the Radeon? It's worked fairly well so far. How would I check if a Radeon card could be better?

I'm not unwilling to go ahead and pay for some more video cards if I'll get better results, but I just want to make sure if I will or not.

The new version of GM will work with NVidia cards by interfacing with Powerstrip. This means you can use your current setup, so if you have created your resolutions with Soft-15kHz or even Powerstrip, then GM will pick them. But the interesting part here is that if you enable the -powerstrip option GM can also recalculate the timings for a given resolution and have it available on the fly. If you're familiar with Powerstrip you'll know it has a limitation that it can only store a custom timing for each resolution. Well, this method overrides this limitation, so for example, you only need to create an instance of the 256x224 resolution, and GM will adjust its vertical refresh on the fly for all the variations required. However, you're still limited by the NVidia drivers that only allow defining 31 custom resolutions simultaneously.

For my tests I used one Geforce Go 7400, which might be similar to your card. I noticed having some issues with low dotclocks, so I ended up using this mode list (lower resolutions are doubled on the horizontal):

I achieved pretty decent results with this method. Before you decide whether to switch to ATI, I'd appreciate if you tested this. Just make sure to backup your current video modes, because GM will overwrite whatever you have carefully tweaked with Powerstrip and it doesn't restore it afterwards, so you may end up loosing your current settings. Powerstrip will only "remind" the last timings used for each mode, whatever they are.

This method is not perfect, unfortunately. We have to trust on Powerstrip for succesfully creating the desired dotclock, but sometimes the obtained dotclock is too off and we end up with a lowered refresh rate, or it's not even stable. These are things that you can sort out when you create a mode manually, but an algorithm can't know beforehand whether the target dotclock will work or not, unless you create a black list or something. Fortunately, you can often identify the problematic dotclock ranges and avoid them, that's what I did by doubling some resolutions on the table above. So it definitely requires some effort on your part to get everything working. This is experimental stuff after all.

On the other hand with Radeon cards we don't need third party software, the Catalyst driver allows us to redefine custom timings on the fly and its dotclock setting is much much more reliable. Apart from the fact that once hacked they allow for more than a hundred custom modes simultaneously.

The new version of GM will work with NVidia cards by interfacing with Powerstrip. This means you can use your current setup, so if you have created your resolutions with Soft-15kHz or even Powerstrip, then GM will pick them. But the interesting part here is that if you enable the -powerstrip option GM can also recalculate the timings for a given resolution and have it available on the fly. If you're familiar with Powerstrip you'll know it has a limitation that it can only store a custom timing for each resolution. Well, this method overrides this limitation, so for example, you only need to create an instance of the 256x224 resolution, and GM will adjust its vertical refresh on the fly for all the variations required. However, you're still limited by the NVidia drivers that only allow defining 31 custom resolutions simultaneously.

That's great, but does it have to use an automatically calculated timing value? I prefer to adjust all the timing values myself in Powerstrip, so I can have both a correct refresh rate and the precise geometry that I want. I do this starting with test patterns, and then adjust it for practical things in the game itself, like overscan cutting off health bars, highscore, etc.

For example, could I tell GroovyMAME the exact timing values to use with 320x240 when it loads up a neogeo.c game?

For my tests I used one Geforce Go 7400, which might be similar to your card. I noticed having some issues with low dotclocks, so I ended up using this mode list (lower resolutions are doubled on the horizontal):

Horizontal doubling should be no problem, I think my Super Emotia techically puts out 640x240; it doesn't really matter, same scan rates. I've gotten pretty good results with low resolutions so far though. I had Mario Bros. running, which is 256x224. I think I actually had it centered in 256x240 or 304x240 (can't remember which atm), but I was able to push the black borders into the overscan.

I achieved pretty decent results with this method. Before you decide whether to switch to ATI, I'd appreciate if you tested this. Just make sure to backup your current video modes, because GM will overwrite whatever you have carefully tweaked with Powerstrip and it doesn't restore it afterwards, so you may end up loosing your current settings. Powerstrip will only "remind" the last timings used for each mode, whatever they are.

You can save your timing values as a shortcut in Powerstrip. After making changes, you can just double click the shortcut to revert. Pretty convenient.

This method is not perfect, unfortunately. We have to trust on Powerstrip for succesfully creating the desired dotclock, but sometimes the obtained dotclock is too off and we end up with a lowered refresh rate, or it's not even stable. These are things that you can sort out when you create a mode manually, but an algorithm can't know beforehand whether the target dotclock will work or not, unless you create a black list or something. Fortunately, you can often identify the problematic dotclock ranges and avoid them, that's what I did by doubling some resolutions on the table above. So it definitely requires some effort on your part to get everything working. This is experimental stuff after all.

That's great, but does it have to use an automatically calculated timing value? I prefer to adjust all the timing values myself in Powerstrip, so I can have both a correct refresh rate and the precise geometry that I want. I do this starting with test patterns, and then adjust it for practical things in the game itself, like overscan cutting off health bars, highscore, etc.

For example, could I tell GroovyMAME the exact timing values to use with 320x240 when it loads up a neogeo.c game?

That's not possible yet I'm afraid, the whole idea was to do everything automatically. But adding raw modeline support is something I wanted to have indeed, and it's not in this version just because I run out of time.

The main idea with GM is to give it the information (crt_range options) so it will create modelines that are perfectly centered, without the need of further tweaking. So your efforts are focused on finding these accurate timing specs that result in correct geometry, instead of manually adjusting hundreds of modes. Once you get this working, you never want to go back to the paleomethod.

However, the problem is, that's the theory. In the real world you find situations where creating general timing specs doesn't work so well, for instance with TVs that internally readjust their geometry (Sony, etc.). So for these cases, it would be nice to also accept a precalculated modeline. This way you have the best of both worlds.