E ) P e r - g a m e c o n f i g u r a t i o n
To force specific MAME and Groovy MAME settings into one only game/machine (or just the games from a particular MAME driver), a machinename.ini file should be placed in MAME's INI folder (or a drivername.ini in ini\source, for the MAME driver case). The machinename is the exact name of the particular romset (including the ones for home systems, as their BIOS romsets) in MAME, without the extension. Keep in mind the priority order for INI files, being mame.ini the lowest priority and romname.ini the highest; they work as transparent layers.
Be aware that the Switchres engine inside Groovy MAME sets several options automatically. Its option setting priority is just above mame.ini and below all other INI files. So bear this in mind when modifying options in mame.ini as your changes may be overridden by Groovy MAME itself. On the contrary, anything you set in any other particular INI file will have preference over Switchres' automatic option setting, as is the case of -syncrefresh, explained above.
The format for the particular INI files is identical to mame.ini's. When creating specific game or driver INI files, do never copy the whole mame.ini file, just create a text file only with the option(s) you want to override; failing to do so will result in Groovy MAME's inability to set options automatically.
A pretty common case of specific configuration is the -bios option for those arcade games which originally share a mother system (Neo-Geo MVS, ST-V...). The mother system's BIOS usually determines certain aspects such as the region for every game under this hardware, and MAME comes with a preset BIOS version for every system which needs to be changed attending to the user's preferences. Therefore, as this is a per-driver option, a drivername.ini file should be created within ini\source folder detailing the -bios value according to the name of the desired BIOS version in MAME. This can be specified in a per-game basis too, in case there's interest.
What follows is the video options prone to be specified in a per-game basis, though generally Groovy MAME under VMM's super resolutions method is preset so that there's no need for specific configurations with the exception of the frame delay feature. Remember that you can always know the video mode being called by Switchres when you're running a game by pressing TAB and going to Machine information.
1. resolution 2560x0
Groovy MAME tweaks CRT Emudriver's video modes on the fly in order to create the gamut of refresh rates required for every game, only limited by the display hardware in use, so, in principle, there's no need to have all those refresh rates predefined in your system. It is necessary, though, that the different resolution modes GM will use (disregarding the refresh, and no matter if super or not) are installed as explained in CRT Emudriver's installation guide [ > ].
Notice that GM also supports dynamic video mode switching for those games programmed to do that.
The value 2560x0 denotes that the super resolutions method is being used. Here, a width of 2560 pixels is forced for all games, while the 0 acts as a wildcard for the vertical resolution (that is, the number of lines), so Groovy MAME will be free to pick the most convenient height from the ones available, applying integer scaling whenever possible.
Due to the nature of CRT technology, the results with the super resolutions method are in most cases virtually the same as when generating the native modes. However, some visible artifacts may appear in scrolling games due to non-integer horizontal scaling. These are usually hard to notice, but the user may prefer for these cases to force a particular video mode already predefined in his system. For this, a machinename.ini file must be created containing the line:
GM will use the optimal vertical refresh by itself, so, again, it doesn't have to be already installed. If a video mode with the desired values for X and Y isn't actually installed in the system, the command -modeline can be used for this matter, which is explained in the next section.
Be aware that using super resolutions not only helps to keep the system with very few video modes (Windows 7 will most likely slow down your system at some point with a long predefined video modes list), it also serves to minimize the need of centering the picture horizontally with every case. Nevertheless, using a super resolution is always more CPU- and GPU-demanding than using the original video mode.
Remember to never set the desktop to the same resolution you later want to use in-game -- doing this prevents GM from editing its refresh rate, as it becomes read-only.
2a. sync_refresh_tolerance 2.0
2b. autosync 1
For those exceptional cases that the desired vertical refresh cannot be achieved due to monitor limitations, controlling how off the obtained refresh must be in order to trigger triple buffering is possible by way of this option. The default value is 2 Hz, but a machinename.ini can include this line with the value desired by the user for that case. Therefore, increasing this value in mame.ini can be used as a general way to enable -syncrefresh even in those cases where the refresh is off (at the cost of reducing the game's original speed).
With -autosync enabled (1), -syncrefresh will be activated automatically if the refresh difference is below -syncrefresh_tolerance. If the refresh difference is greater than -syncrefresh_tolerance, -triplebuffer (multithreaded blitting) will be activated. With -autosync disabled (0), -syncrefresh and -triplebuffer will need to be configured manually as explained in the previous section.
3. frame_delay 0
This is actually the only option where the Groovy MAME user must really make an extra effort of testing and configure the emulator in a per-game basis in order to get the best possible emulation out of it (particularly, regarding the input lag issue), since this feature is heavily dependent on the computer's CPU and the usage every emulated game in particular makes of it.
The frame delay feature actually serves two purposes:
- Delaying the emulation of a frame in order to get the most up-to-date input state before going into the emulation itself
- Bypassing a frame queue that's built in the ATI video drivers when Direct 3-D is used which adds a lag of 2-3 frames by itself
For actually getting the former, a CPU fast enough to emulate each frame at a fraction of the time that the original hardware did would be required, so this option is implemented in gradual steps from 1 to 9, where 1 stands for 10 % of a frame period and 9 stands for 90 %. This way, the user is able to adapt it to get the longer possible delay with the hardware in use.
Frame delay can be configured either, through the INI file or via GM's on-the-fly menu accessible by pressing the TAB key during the emulation process, in the Slider controls submenu. Any change made through the latter will permanently be stored in the emulated machine's .cfg file (cfg folder), and will have priority over any INI definition (which will be understood just as the default value, the one in use if it's not changed with the Slider submenu, that is).
Though you can previously check the suggested frame delay value for every machine with the -bench command, the easiest global approach may be to always start with 9 or 8 and decrement it until a stable performance is got (check MAME's display for emulation speed when running every game with F11 key -- it must not be lower than 100 % in any instance, so the tests should be long and through enough).
In other words, the higher you can set it without causing performance issues, the better input lag figures due to the emulation process itself you'll get, being essentially negligible with 9 and close enough to that with 7 or 8. Under Windows XP, try to just never leave it at 0 if you care about the subject, anyway.
Note: For usage of this feature with some particular emulated machines, it may be necessary to set frame_delay in the machinename.ini or drivername.ini file, even if it's only with the value of 1 (and then setting it higher through the Slider submenu). You'll notice this when you only set frame delay through the Sliders submenu and the next time running the emulation, the game/machine's speed is not correct (check it on the fly with MAME's show game speed key).
4. vsync_offset 0
The V-sync offset feature only makes sense if a tearing effect appears with -frame_delay. Tearing happens with high resolutions, when there's substantial scaling going on, be it 640 x 480 or 2560 x 240. At high resolutions, the time it takes the GPU to scale a frame starts being longer than the blanking period itself, which may cause static tearing when -frame_delay is used.
To compensate this issue, -vsync_offset forces the render code to be called a number of lines ahead of time. Ideally, using a proper value realigns the render completion with the end of the blanking period, cleanly removing all tearing, but you'll need a fairly fast graphics card in order to fully remove tearing. The higher the tearing line appears on the screen initially, the faster your card is, and the more chances of completely hiding tearing through -vsync_offset. The value should be typed as the estimated number of scan lines required to hide the effect for every particular case.
Notice that it'll be required to lower the -frame_delay value proportionally to the amount of lines set in -vsync_offset.
5. changeres 1
This option controls the video mode auto-switching in those games which dynamically change their resolution. For disabling this feature, type 0 in place of 1.
6. interlace 1
This option enables interlaced scanning when necessary. For disabling this feature, type 0 in place of 1.