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 the user's system. It 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. Nevertheless, 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:
resolution XxY@f...where XxY@f is the "label" associated with the desired video mode according to Arcade OSD.
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 with a long video modes list -- the execution time of some system calls grows at an exponential rate based on the number of video modes available, according to Calamity), it also serves to minimize the need of centering the picture horizontally with every case.
2. sync_refresh_tolerance 2.0
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).
3. frame_delay 0
This, along with -vsync_offset, is 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 9 is used which adds a lag of 2-3 frames by itself (be aware that Direct 3-D 9 Ex already bypasses it, so there's no need for enabling frame delay with this version of the API for this purpose; just under plain Direct 3-D 9)
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. Notice that, theoretically, using -frame_delay set to 1 would be almost equal to not using -frame_delay at all (0) -- just 10 % more chances of catching the input in time for the next frame. The actual gain would come from raising from 1 to 9, and that gain only translates to the last remaining frame of lag and only statistically (that is, it may help only with 33 % of the total frames), so, in the end, the effect may not be really relevant.
The risk of enabling -frame_delay is that it becomes possible that several frames of emulation get into the same vertical retrace, especially if the emulation of a given game is fast enough on the target CPU, which results in an accelerated speed. Depending on the CPU and the emulated game's requirements, 1-2 most likely will be too low and 8-9, too high, so it's suggested to check how CPU-demanding the game is (by running it unthrottled and with frame delay disabled) and, if it's, say, around 700-1000 %, then set frame delay to 3 or 4, and then check if there're not emulation/speed issues. A better global approach, though, may be to always start with 8 and decrement it until a stable performance is got (check MAME's display for emulation speed when running every game).
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.
7. audio_latency 2.0
Depending on the emulated game and performance, lowering this value may reduce audio lag.
