Topic: Groovy MAME: Installation and quick configuration (2019 guide)

We've made this with two purposes -- helping to get Groovy MAME (GM) working and properly configured as soon as possible for anybody with no deep knowledge of MAME [ > ] itself and the technicalities involved in CRT Emudriver, and summarizing Groovy MAME's features from Groovy MAME's official message board [ > ], where they have been developed, explained, discussed and well, kind of lost due to that Site's nature. It's strongly recommended to read and broadly understand this tutorial for anybody not entirely familiar with the emulator, but keep in mind this is not GM's official documentation and will be outdated sooner o later.

This guide assumes, on the other hand, that the reader has some understanding of the different video modes used by old games and of how they are displayed on CRT monitors.

Groovy MAME is maintained and developed these days by Calamity alone, so it's CRT Emudriver's best friend. At the moment of posting this, MAME has just reached its version 0.212, and the possibilities to reduce audio latency to virtually the same level as the original hardware have become a reality. This couples with GM's unique frame delay engine to essentially match the original experience on actual hardware regarding response times (lag) if used properly, so there's currently a lot more to GM than just the capability to emulate the games on 15-kHz CRT monitors at their native vertical frequency and resolution modes.

The tutorial tries to be as to-the-point as possible, so only the necessary aspects have been explained. With that in mind, it's been restricted to Windows 7 installations and CRT usage -- our recommended environment. Flat-panel users can also take advantage of many of GM's unique features, though the particular tweaks they require will not be covered here. Usage of 31-kHz 120-Hz monitors for natively 15-kHz modes also involves some particularities which would require their own thread.

We believe it's better using the "official" board at BYOAC to discuss anything GM-related, but feel free to make posts on the subject here in this thread too. Remember that having Groovy MAME updated as much as possible is always recommended since it's improving with every Switchres version.

Re: Groovy MAME: Installation and quick configuration (2019 guide)


Re: Groovy MAME: Installation and quick configuration (2019 guide)

G R O O V Y   M A M E :   I N S T A L L A T I O N   A N D   Q U I C K   C O N F I G U R A T I O N   
( W I N    7   -   S U P E R   R E S O L U T I O N S   -   C R T )

A )   F i r s t   s t e p s

1. Download the latest version of Groovy MAME [ > ] attending to your OS (Windows XP/Windows 7 or higher/Linux). Notice the 64-bit versions of Windows are required (though there use to be unofficial 32-bit builds posted in the BYOA forums if you happen to need them) and that this guide will only cover W7 since it's still the most reliable (and user-friendly OS) for GM usage.

You'll also need the game, system BIOS and devices romsets for the corresponding MAME version, which should be placed in a permanent directory in the target computer. Game romsets of home systems under MAME's software list methodology need predetermined directories; check this link [ > ] in order to learn about software lists and software storage if you're interested in emulation of home systems with Groovy MAME.

2. Create a directory for MAME in the target computer, say, C:\GROOVYMAME, and extract into it the content of Groovy MAME's compressed file. A file with the name mame64.exe should be there. Right-click it, go to Properties, Compatibility and give it Admin. privileges.

3. Make sure the following folders are there: C:\GROOVYMAME\ini and C:\GROOVYMAME\ini\source. The former will be the folder to place per-game (per-machine, in the case of home systems) INI configuration files, while the latter will host per-driver INI configuration files. These INI files will only be needed when we want specific MAME settings for a game or group of games, since they'll get priority over Groovy MAME's main configuration file mame.ini. Remember this.

4. If it's not present after the extraction, create mame.ini: Right-click mame64.exe and click Send to, Desktop (create shortcut). Place this desktop shortcut into GM's directory (paste in C:\GROOVYMAME). Right-click it, go to Properties, Direct access label, and, in the target field add " -cc" -- that is, if it has:

C:\GROOVYMAME\mame64.exe must have:

C:\GROOVYMAME\mame64.exe -cc

Now make it accept the change and double-click this direct access.

5. Make sure a mame.ini file is now in your Groovy MAME directory and delete the direct access you pasted there in the previous step.

6. For launching the games/machines, you have now the option to pick a MAME-compatible frontend or just resort to command-line operation and/or MAME's own GUI (which just requires double-clicking mame64.exe once the configuration process has been finished). In the former case, check the internet to see what's better suited for your tastes keeping in mind the minimum screen resolution required by the frontend to operate and also remember to configure it as you make sure it does not overwrite the existing mame.ini file nor create brand-new ones for the games/drivers. The Display options in MAMEUI (the frontend officially included in MAME since 0.171) will do, so don't touch them!

B )   C R T   E m u d r i v e r   a n d   C R T   T o o l s

1. Create a directory in your target system for CRT Emudriver 2.0, VMM and Arcade OSD [ > ] and download the suite.

Be aware that CRT Emudriver 2.0 beta 11 and higher will totally remove the anti-flicker filter present in interlaced display modes. If, for some reason, you prefer this filter, you must install CRT Emudriver 2.0 beta 10 and use it with the latest version of CRT Tools, since they'll be perfectly compatible.

Extract them into your folder.

2. Follow Calamity's own installation guides you'll find in the previous link up to the end -- you'll get your system ready for 15-kHz modes and video mode customization as well as Groovy MAME ready for super resolutions, just remember to set the directory of your Groovy MAME's executable file (mame64.exe) and check Export monitor settings to Groovy MAME in VMM's MAME tab.

Re: Groovy MAME: Installation and quick configuration (2019 guide)


Re: Groovy MAME: Installation and quick configuration (2019 guide)

C )   C o n f i g u r i n g   G r o o v y   M A M E

This is Groovy MAME 0.212's mame.ini's content right after creating it after following Calamity's CRT Emudriver installation guide (note: an alternate ROM path has been added as an example):

readconfig                1
writeconfig               0

homepath                  .
rompath                   roms;C:\ROM\MAME
hashpath                  hash
samplepath                samples
artpath                   artwork
ctrlrpath                 ctrlr
inipath                   .;ini;ini/presets
fontpath                  .
cheatpath                 cheat
crosshairpath             crosshair
pluginspath               plugins
languagepath              language
swpath                    software

cfg_directory             cfg
nvram_directory           nvram
input_directory           inp
state_directory           sta
snapshot_directory        snap
diff_directory            diff
comment_directory         comments

autosave                  0
rewind                    0
rewind_capacity           100
record_timecode           0
exit_after_playback       0
snapname                  %g/%i
snapsize                  auto
snapview                  internal
snapbilinear              1
statename                 %g
burnin                    0

autoframeskip             0
frameskip                 0
seconds_to_run            0
throttle                  1
syncrefresh               0
autosync                  1
sleep                     1
speed                     1.0
refreshspeed              0

keepaspect                1
unevenstretch             1
unevenstretchx            0
unevenstretchy            0
autostretchxy             0
intoverscan               0
intscalex                 0
intscaley                 0

rotate                    1
ror                       0
rol                       0
autoror                   0
autorol                   0
flipx                     0
flipy                     0

artwork_crop              1

brightness                1.0
contrast                  1.0
gamma                     1.0
pause_brightness          0.65
effect                    none

beam_width_min            1.0
beam_width_max            1.0
beam_intensity_weight     0
flicker                   0

samplerate                48000
samples                   1
volume                    0

coin_lockout              1
mouse                     0
joystick                  1
lightgun                  0
multikeyboard             0
multimouse                0
steadykey                 0
ui_active                 0
offscreen_reload          0
joystick_map              auto
joystick_deadzone         0.3
joystick_saturation       0.85
natural                   0
joystick_contradictory    0
coin_impulse              0

paddle_device             keyboard
adstick_device            keyboard
pedal_device              keyboard
dial_device               keyboard
trackball_device          keyboard
lightgun_device           keyboard
positional_device         keyboard
mouse_device              mouse

verbose                   0
log                       0
oslog                     0
debug                     0
update_in_pause           0

comm_localport            15112
comm_remoteport           15112
comm_framesync            0

drc                       1
drc_use_c                 0
drc_log_uml               0
drc_log_native            0
cheat                     0
skip_gameinfo             0
skip_mandatory_fileman    0
uifont                    default
ui                        cabinet
confirm_quit              0
ui_mouse                  1
language                  English
nvram_save                1

autoboot_delay            0
console                   0
plugins                   1

http                      0
http_port                 8080
http_root                 web

modeline_generation       1
monitor                   generic_15
orientation               horizontal
connector                 auto
interlace                 1
doublescan                1
super_width               2560
changeres                 1
powerstrip                0
lock_system_modes         1
lock_unsupported_modes    1
refresh_dont_care         0
dotclock_min              0
sync_refresh_tolerance    2.0
frame_delay               0
vsync_offset              0
black_frame_insertion     0
modeline                  auto
ps_timing                 auto
lcd_range                 auto
crt_range0                auto
crt_range1                auto
crt_range2                auto
crt_range3                auto
crt_range4                auto
crt_range5                auto
crt_range6                auto
crt_range7                auto
crt_range8                auto
crt_range9                auto

uimodekey                 SCRLOCK

uifontprovider            auto

output                    auto

keyboardprovider          auto
mouseprovider             auto
lightgunprovider          auto
joystickprovider          auto

debugger                  auto
debugger_font             auto
debugger_font_size        0
watchdog                  0

numprocessors             auto
bench                     0

video                     auto
numscreens                1
window                    0
maximize                  1
waitvsync                 0
monitorprovider           auto

screen                    auto
aspect                    auto
resolution                auto
view                      auto
screen0                   auto
aspect0                   auto
resolution0               auto
view0                     auto
screen1                   auto
aspect1                   auto
resolution1               auto
view1                     auto
screen2                   auto
aspect2                   auto
resolution2               auto
view2                     auto
screen3                   auto
aspect3                   auto
resolution3               auto
view3                     auto

switchres                 1

filter                    0
prescale                  1

gl_forcepow2texture       0
gl_notexturerect          0
gl_vbo                    1
gl_pbo                    1
gl_glsl                   0
gl_glsl_filter            1
glsl_shader_mame0         none
glsl_shader_mame1         none
glsl_shader_mame2         none
glsl_shader_mame3         none
glsl_shader_mame4         none
glsl_shader_mame5         none
glsl_shader_mame6         none
glsl_shader_mame7         none
glsl_shader_mame8         none
glsl_shader_mame9         none
glsl_shader_screen0       none
glsl_shader_screen1       none
glsl_shader_screen2       none
glsl_shader_screen3       none
glsl_shader_screen4       none
glsl_shader_screen5       none
glsl_shader_screen6       none
glsl_shader_screen7       none
glsl_shader_screen8       none
glsl_shader_screen9       none

sound                     auto
audio_latency             2.0

pa_api                    none
pa_device                 none
pa_latency                0

bgfx_path                 bgfx
bgfx_backend              auto
bgfx_debug                0
bgfx_screen_chains        default
bgfx_shadow_mask          slot-mask.png
bgfx_avi_name             auto

priority                  0
profile                   0

menu                      0

hlslpath                  hlsl
hlsl_enable               0
hlsl_oversampling         0
hlsl_write                auto
hlsl_snap_width           2048
hlsl_snap_height          1536
shadow_mask_tile_mode     0
shadow_mask_alpha         0.0
shadow_mask_texture       shadow-mask.png
shadow_mask_x_count       6
shadow_mask_y_count       4
shadow_mask_usize         0.1875
shadow_mask_vsize         0.25
shadow_mask_uoffset       0.0
shadow_mask_voffset       0.0
distortion                0.0
cubic_distortion          0.0
distort_corner            0.0
round_corner              0.0
smooth_border             0.0
reflection                0.0
vignetting                0.0
scanline_alpha            0.0
scanline_size             1.0
scanline_height           1.0
scanline_variation        1.0
scanline_bright_scale     1.0
scanline_bright_offset    0.0
scanline_jitter           0.0
hum_bar_alpha             0.0
defocus                   0.0,0.0
converge_x                0.0,0.0,0.0
converge_y                0.0,0.0,0.0
radial_converge_x         0.0,0.0,0.0
radial_converge_y         0.0,0.0,0.0
red_ratio                 1.0,0.0,0.0
grn_ratio                 0.0,1.0,0.0
blu_ratio                 0.0,0.0,1.0
saturation                1.0
offset                    0.0,0.0,0.0
scale                     1.0,1.0,1.0
power                     1.0,1.0,1.0
floor                     0.0,0.0,0.0
phosphor_life             0.0,0.0,0.0
chroma_mode               3
chroma_conversion_gain    0.299,0.587,0.114
chroma_a                  0.64,0.33
chroma_b                  0.30,0.60
chroma_c                  0.15,0.06
chroma_y_gain             0.2126,0.7152,0.0722

yiq_enable                0
yiq_jitter                0.0
yiq_cc                    3.57954545
yiq_a                     0.5
yiq_b                     0.5
yiq_o                     0.0
yiq_p                     1.0
yiq_n                     1.0
yiq_y                     6.0
yiq_i                     1.2
yiq_q                     0.6
yiq_scan_time             52.6
yiq_phase_count           2

vector_beam_smooth        0.0
vector_length_scale       0.5
vector_length_ratio       0.5

bloom_blend_mode          0
bloom_scale               0.0
bloom_overdrive           1.0,1.0,1.0
bloom_lvl0_weight         1.0
bloom_lvl1_weight         0.64
bloom_lvl2_weight         0.32
bloom_lvl3_weight         0.16
bloom_lvl4_weight         0.08
bloom_lvl5_weight         0.06
bloom_lvl6_weight         0.04
bloom_lvl7_weight         0.02
bloom_lvl8_weight         0.01
lut_enable                0
ui_lut_enable             0

triplebuffer              0
full_screen_brightness    1.0
full_screen_contrast      1.0
full_screen_gamma         1.0

global_inputs             0
dual_lightgun             0

dtd                       1

Open mame.ini and find the following lines in order to make the suggested changes below. The settings in mame.ini affect any game without a specific INI file in the INI folder. (The official explanation of all the Groovy MAME's features are here; check it out for further elaboration.)

1. video                     d3d

Leaving this instruction as auto is fine as well. Groovy MAME 0.212 under Windows 7 uses Direct 3-D 9 Ex as the preferred API, which allows for an improved frame latency. Notice that Direct Draw stopped being supported by MAME in version 0.171, whereas Direct 3-D 9 Ex only is supported by Groovy MAME 0.167 onwards. (Direct 3-D 9 is used by the Windows XP build instead, since this OS is not compatible with the Ex version.)

2. orientation               horizontal

Change it to vertical if the monitor in use has vertical orientation. Change it to rotate_l or rotate_r if you're using a rotating monitor set (anti-clockwise and clockwise, respectively).

Note that Switchres manages rotation options internally, so anything in mame.ini regarding screen rotation will be overridden, since the priority of Switchres option auto-setting (Core Switchres Options in mame.ini) is just above mame.ini.

3a. syncrefresh              0
3b. triplebuffer              0
3c. waitvsync              0

Due to changes in MAME's original video performance, Groovy MAME manages certain options such as -syncrefresh and -triplebuffer automatically for the user's convenience, and it is required that these options are left as 0 in mame.ini for this to be possible. If the target refresh is achieved, Groovy MAME will select -syncrefresh, but if the desired refresh cannot be achieved due to monitor limitations, -triplebuffer will be used instead.

When -syncrefresh is used, Groovy MAME will synchronize both, video and audio emulation to the video card's refresh, resulting in the same perfect screen scrolling you get with the real hardware. You can force -syncrefresh for all games by enabling it in mame.ini, but this will make some of them run at an incorrect speed when the intended refresh cannot be achieved, which will be noticed by the modified sound pitch.

These particular cases where the intended refresh speed cannot be achieved are typically found when running (by way of rotating the picture) the games designed for vertically-oriented monitors on horizontally-oriented monitors and using a progressive mode. Here, -triplebuffer allows to keep the speed at 100% at the cost of smooth scrolling.

Therefore, do never enable -triplebuffer as a general setting, as it degradates the emulation experience of games for which it's not strictly required. There's no increase of input lag associated to this option, however, since it's not the same -triplebuffer feature mainline MAME implements (blitting is performed here in an additional thread).

Also, be aware that -syncrefresh at 0 in other than mame.ini does actually disable this option for that particular game/machine or group of games. The value 0 for -syncrefresh means automatic only in regards to mame.ini.

4a. sleep            0
4b. priority            1

With these values, GM will make use of your CPU as much as possible against other simultaneous processes. These can be considered advisable especially if you're willing to use Port Audio for low-latency audio, though enabling -priority could cause issues with other programs in use or even your control inputs and Windows itself, in which case should be changed back to 0.

5. cheats            1

Enabling this feature like this will give you access to new options in the Slider Controls submenu related to emulated clocks. These are almost always better if kept intact, however some particular emulation bugs are hidden if the emulated CPU clock value is modified. When you know exactly which are these, you can use this feature. Contrarily to baseline MAME, GM will save these settings in the per-game .cfg files when you close the emulation.

6. uifont            uismall.bdf

This will get you a more legible font for the internal menus during GM's operation particularly under low resolutions.

Re: Groovy MAME: Installation and quick configuration (2019 guide)


Re: Groovy MAME: Installation and quick configuration (2019 guide)

D )   C o n f i g u r i n g   t h e   P o r t   A u d i o   o p t i o n s

These are also done as global settings in mame.ini, though for clarity's sake, they get their own section here. They're baseline MAME's features actually (succeeding Inteall's ASIO implementation for Groovy MAME, now deprecated), but due to their intimate connection with GM's philosophy, it's well worth explaining them here so that every GM user makes use of them without hesitation. Their purpose is reducing the audio latency to the very bare minimum level, virtually indistinguishable from the original hardware's.

Find these commands in mame.ini and change their values as follows:

sound                    portaudio
audio latency          0
pa_api                   "Windows WDM-KS"
pa_device                 none
pa_latency                 0.001

Alternatively, you can use these:

pa_api                    "Windows WASAPI"
pa_latency              0.003334

Which one to pick depends on your hardware and system configuration, but under W7 with updated audio drivers and a decent CPU, both should be available and give good results. Try one or the other if you get stuttering or distorted sound when running any game, and/or set a bit higher the pa_latency value (keep in mind they're measured in seconds and the ones above should be low-enough safe settings, so try, say, 0.00125 instead of 0.001, then 0.01...).

If you get no sound at all, it may be another application in the background which is using audio, preventing from Port Audio activation.

Usually the pa_device instruction has to be defined as well, so, in that case or just to make sure, follow these steps:

1. Go to C:\Windows\System32 and double-click cmd.exe

2. Type:

mame64 -sound portaudio -v

and press enter

3. Close the MAME instance (press Esc)

4. In the command-line window, look near the end of the text for the lines which tell you the output devices for either, WDM-KS or WASAPI; you must note the exact name of one of them, for instance, "Speaker (Realtek HD Audio output)".

5. In the mame.ini file, type the device's name as it is with quotation marks if it's more than one word, for instance:

pa_device                 "Speaker (Realtek HD Audio output)"

(If there's still no proper sound and you have an integrated Realtek sound card you might try other listed APIs such as MME or "Windows directsound" in the pa_api instruction.)

In order to check the results of your configuration, follow the steps 1 to 3 and look for the latency line in the command-line window -- the resulting value will be given in ms.

Re: Groovy MAME: Installation and quick configuration (2019 guide)


Re: Groovy MAME: Installation and quick configuration (2019 guide)

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:

resolution                XxY

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.

Re: Groovy MAME: Installation and quick configuration (2019 guide)


Re: Groovy MAME: Installation and quick configuration (2019 guide)

F )   S o l v i n g   o v e r s c a n   a n d   g e o m e t r y   i s s u e s

As a previous note, be aware that we always recommend the usage of monitors/TVs with adjustable geometry settings. Most will have them, but for many TV sets it'll not be easy to get access to the service menu or the devices which control them. Arcade games (and many old PC games) were conceived for monitors with easy-to-control screen geometry, so it wasn't really important which model or video mode they used and the consequent variations in screen geometry parameters against other samples (position, borders, etc.). Therefore, you can't expect a universal solution by software which sets a perfectly adjusted visible area on screen for every game in MAME so that you won't ever need to make monitor tweaks. Super resolutions (and only super resolutions) will essentially get the same horizontal amplitude for all the games, but you'll need to manually adjust the vertical size if you want to properly display games with different-enough video modes, though we'll show a way here (two ways, actually) to control the vertical position by software in case you want to leave at least that monitor setting intact.


Different monitors require different definitions for the monitor's specifications through one or more CRT range lines in our system, and it's the CRT range what determines overall screen geometry. With Video Mode Maker, a CRT range was set in the process of installation; it's located in the Monitor settings tab, and it can be changed by another preset and even edited at will. It's likely that with the default preset you don't get a perfectly centered area under your current/default monitor parameters, so you may start by editing it.

If you'll be using the monitor also with devices other than the PC for emulation (say, a game console), a smart approach may be firstly adjusting the monitor parameters to get the best geometry for these devices, given that they'll normally won't give you the option to do it internally.

In order to edit a preset (the one named Arcade 15.7 kHz - standard resolution is generally a good one to use as the basis for 15-kHz monitors, including TV sets), you need to know well what a CRT range line consists of, namely:


HfreqMin-HfreqMax, VfreqMin-VfreqMax, HFP, HSP, HBP, VFP, VSP, VBP, HPol, VPol, PLMin, PLMax, ILMin, ILMax

HfreqMin-HfreqMax -- horizontal frequency range (Hz) 

VfreqMin-VfreqMax -- vertical frequency range (Hz) 

HFP -- horizontal front porch   

HSP -- horizontal sync pulse

HBP -- horizontal back porch 

VFP -- vertical front porch

VSP -- vertical sync pulse

VBP -- vertical back porch

HPol -- horizontal sync. polarity

VPol -- vertical sync. polarity

PLMin -- lower limit of possible lines in progressive modes

PLMax -- upper limit of possible lines in progressive modes

ILMin --  lower limit of possible lines in interlaced modes

ILMax --  upper limit of possible lines in interlaced modes

Usually, you'll just need to correct the horizontal position, so take a look at this example:

15625-16200, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576 (original Arcade 15.7 kHz preset)

15625-16200, 49.50-65.00, 2.000, 4.700, 6.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576 (edited Arcade 15.7 kHz preset)

By picking the aforementioned preset in the corresponding field and changing this value with Notepad when clicking the edit button in VMM, you'll center the picture horizontally according to the demands of most NTSC consoles on many Trinitron TV sets, so you won't need to enter the TV's service menu and adjust this setting every time you change from your PC to your consoles and viceversa.

If, for instance, you also get the image positioned too low, you'll need to reduce the vertical back porch value:

15625-16200, 49.50-65.00, 2.000, 4.700, 6.000, 0.064, 0.192, 1.020, 0, 0, 192, 288, 448, 576

And so on.

Given that you can export the defined CRT range directly to Groovy MAME as explained before, you don't need to also define this in Groovy MAME's INI file, though you can do it if you want to by finding and editing this line:

monitor                   generic_15

(Yet more presets here.)

Much like with VMM, it's possible to set custom values by the monitor's particular specs. To do that, type custom in place of generic_15 and add the values in the crt_range lines accordingly, taking always as a reference one of the given samples and their effect. Check VMM's tutorial [ > ] for further elaboration.


Groovy MAME lets us define the modeline(s) in the machinename.ini files, overriding the definitions in MAME's INI file. This is extremely useful to solve particularly geometry problems, such as the vertical centering derived from the disparity of the vertical scan rates or the overscan-into-underscan issues in quite a few arcade games.

The easiest way to tweak modelines per-game is:

1. Run the game with verbose enabled: Start menu, Run, C:\GROOVYMAME\mame64.exe machinename -v

2. Exit Groovy MAME and launch Arcade OSD. You'll notice the Get mode from clipboard option is enabled, go there. It will launch the last mode used by Groovy MAME, including custom timings.

3. Make the geometry changes as desired in A-OSD. Remember that you can't modify the vertical amplitude by software. 

4. When done, select Back and Copy modeline to clipboard. Exit the program.

5. Open Notepad, press CTRL + V. Now copy to the clipboard the modeline line, not the CRT range line, and paste it in your machinename.ini:

modeline "2560x240_60 kHz Hz" PixelClock, HRes, HSyncStart, HSyncEnd, HTotal, VRes, VSyncStart, VSyncEnd, VTotal, hsync, vsync

6. Save changes and test the game/machine.


- Regarding the modeline option, the only requirement to use it is having a modeline already installed in your system with the same active width and height.

- Groovy MAME keeps the video mode specifications if modeline is used, but if the mode is defined with the command resolution instead, Groovy MAME will not use the vertical refresh attending to Arcade OSD, but attending to the emulator's request for that game, if vsync is not disabled. The picture won't be scaled if it doesn't match the defined resolution (black borders and some shift will likely appear).

- If resolution is used, the video mode displayed in-game through MAME's menu and splash screen shows the vertical refresh from A-OSD according to that label, which usually won't be the one in actual use for the reason above.

- For minor tweaks, MAME's Slider Controls (reach them also through the TAB menu when running a machine), allows to modify the screen's horizontal and vertical position.

Re: Groovy MAME: Installation and quick configuration (2019 guide)


Re: Groovy MAME: Installation and quick configuration (2019 guide)

G )   E x t r a   t i p s

Calamity also provides us with the following advices for some particular situations:


When using super wide resolutions, there are instances where it'll be convenient enabling fractional scaling on the horizontal axis together with integer scaling on the vertical one. GM uses the following options to control the scaling:

-unevenstretch / -ues -- fractional stretching (default)
-nounevenstretch / -noues -- integer scaling
-unevenstretchx -- fractional stretching on horizontal axis, integer scaling on vertical axis
-intscalex -- horizontal integer scale factor, default is 0 (auto)
-intscaley -- vertical integer scale factor, default is 0 (auto)
-super_width -- defines the width that triggers the new -unevenstretchx option; used for super resolutions (default value is 2560)
-intoverscan -- allows frame cropping when integer scaling is in use

Sample case 1:

A system like the Super Famicom made use of different horizontal resolutions which eventually switch in-game (512 px or 256 px). On the other hand, depending on the game, the video mode can be of 224 or 240 lines (or even 448 interlaced, in some instances), so the vertical resolution is variable as well. Using a super wide resolution mode of 240 horizontal lines will make the in-game switching from 256 to 512 (and viceversa) totally seamless (against an actual mode change) and having fractional horizontal scaling enabled for that is normally required. In the vertical axis, though, we must prevent from any scaling at all to happen, otherwise a 224-lines game would get upscaled to the 240 lines we have defined. So the command in the snes.ini file should be this:


By forcing integer scaling in the vertical axis like this (no value is typed for this command), there'll not be scaling at all in this case, since there's not an integer factor to turn 224 into 240.

Sample case 2:

The Neo Geo platform was a one-resolution hardware which used 320 x 224. Nevertheless (due to compatibility reasons with the consumer market and its need of TV-sets usage), many games on it such as Metal Slug left a predetermined area of the 320 x 224 frame unused, drawing graphics only in an area of 304 x 224 and leaving a border of 8 px-width on each side. This was intended as overscan, an area which should be hidden, and therefore would force us to adjust the monitor settings every time one of these games are launched.

While defining a CRT range with compensated horizontal porch values in these particular games' INI files is the proper solution, a quick-and-dirty approach is possible by chopping off the borders if you have a 304 x 240 mode available in your system. A mslug.ini with the following parameters is due:

resolution 304x240

By defaut, GM will refuse to launch a game in a resolution smaller than the native one. If you force it to do so, that will trigger fractional scaling, in a desperate attempt to push the whole frame through your smaller resolution. To avoid that, you use -noues. Here in this example, -intoverscan would not really be required, but it's been added to clarify the concept, since it tells GM its OK to crop if required to keep integer scaling.

Sample case 3:

Forcing 320 x 240 on a 320 x 256 game without subscaling is possible by adding these commands to the machinename.ini:

resolution 320x240

Here -intoverscan is required in order to avoid GM using fractional scaling and make it crop the frame instead.


Windows 7's video stack adds an absurd overhead to video mode switching -- it's something you're not supposed to do so often in normal applications. With regards to games that dynamically witch resolutions, there are some things that can be done to avoid issues:

- Disable the changeres option in mame.ini. This will leave the game all the time at its default resolution, the one that's reported by MAME's XML. There'll be a single mode change on load, then no in-game mode switching. The problem with this is yhat, very often, the resolution reported is the first one assigned by the hardware initialization, which doesn't match the main video mode used by the game.

- Force a given resolution by means of the resolution option. This by itself will disable mode switching (same as nochangeres) but you can specify the main video mode that's actually used during the game.

- Use super resolutions. By using super resolutions, most mode changes will be unneeded. Only vertical resolution changes will trigger an actual video mode change. This is ideal for some systems (such as Sega Mega Drive) which change horizontal frequency quite often while leaving vertical unchanged. For systems that also change vertical resolution, the previous method is preferred.

Besides this, follow these recommendations when possible:

- Try to keep the mode list as short as possible; this will make mode changes work faster. Super resolutions will be of help here.

- Only enable the outputs you actually use. Each extra output that's enabled exponentially increases the time required by certain graphic API calls (e. g. EnumDisplaySettings).

- Use your frontend as your system shell (instead of explorer.exe). Having the default shell at the background means that upon a mode change, Windows will send messages to all the little things that live on your desktop, asking them to redraw themselves etc., which takes a lot of time.


This comes in handy, for instance, with the systems where MAME mistakenly reports a vertical resolution which doubles the native one. Let's illustrate this with MSX 2 computer series emulation -- MAME always reports a vertical display resolution of 466 pixels for most MSX2/MSXP games, but, in actuality, MSX 2's Screen 5~7 modes displayed either, single-scan (233 lines) or interlaced (466 lines), and very few games used the interlaced modality (and those which did, only used it at some very particular moments). So, when emulating these games on a 15-kHz monitor, the correct approach consists in getting progressive modes of 233 lines instead of the interlaced mode at 466 lines, which, if anything, should only be called at those moments to make the change dynamically.

Until MAME fixes it in the driver's code, other than with hardware de-interlacing, this can only be achieved by installing a super wide resolution of 233 lines in this case (say, 1088 x 233), setting it through machinename.ini, and the commands that follow:

resolution 1088x233
unevenstretch 1
nochangeres 1

Fractional stretching is forced because we need to apply a fractional scale factor of 0.5 to the vertical axis (integer subscaling is not possible since the minimum possible integer factor is 1). The trick to avoid scaling artifacts is to choose a resolution whose height is the exact half of MAME's reported resolution (466). The width is not a problem because we have a super wide resolution.

Using nochangeres 1 is recommended too if the emulated system makes constant resolution changes, as these make the emulation too slow.

End of the guide

Re: Groovy MAME: Installation and quick configuration (2019 guide)


Re: Groovy MAME: Installation and quick configuration (2019 guide)

Let me add a tiny bit of editorialism right here. It's more than a decade now that Calamity has been modifying AMD drivers and developing Groovy MAME with the help of the people at the BYOAC subforum. Unlike other developers, he's humble and discreet and won't ever say this, but the amount of work to extend the number of supported graphic cards, the cool utilities he's created for the usage of Windows on 15-kHz displays, and the improvements in MAME he's made over these years for the expert, non-conforming player is staggering. For properly-emulated pieces and with the right set-up, there's virtually no difference at all between playing them on their original hardware and doing it on Groovy MAME, and that includes the infamous input lag subject -- Calamity pioneered that with the frame delay feature.

So if you find his work and this guide useful and feel like thanking him for it at some point, a thread for buying him an imported beer or something is here: … .php?id=36

Re: Groovy MAME: Installation and quick configuration (2019 guide)

On frame delay -- I'm saving this post by Calamity here explaining the feature, as a reminder:

I'd like to quote schmerzkaufen from other thread, since it'll help me illustrate something I wanted to clarify:

Garegga has about 3 frames of natural lag iirc, but that one you can't touch, Groovy can only eliminate the additional lag that's running on top.


    MAME (official) BGFX -> bgaregga 3fr + vsync 5fr = 8 frames
    MAME (official) d3d -> bgaregga 3fr + vsync 3fr = 6 frames

    Groovy BGFX -> bgaregga 3fr + vsync 3fr = 6 frames
    Groovy d3d9ex (default) -> bgaregga 3fr + vsync 2fr = 5 frames
    Groovy d3d9ex w/ frame_delay 1 -> bgaregga 3fr + vsync 1fr = 4 frames
    Groovy d3d9ex w/ frame_delay 5 -> bgaregga 3fr + vsync 0.5fr = 3.5 frames
    Groovy d3d9ex w/ frame_delay 9 -> bgaregga 3fr + vsync 1.6ms = 3 frames + 1.6 miliseconds (1/10th of a frame)

I think it's important to clarify, so we can properly interpret oomek's results in the future.

When schmerzkaufen says fd 9 equals to 1/10th of a frame of lag, it's true but *only* if you consider the average value. In my opinion we shouldn't use average values, or only use them with care, because it leads to confusions.

Actually, fd 9 means that for 9 out of 10 button presses (90%), the lag is zero (matches original hardware, as jimmer says).

It's only for 1 out of 10 button presses (10%), that the lag is 1 frame, since the button press is not catched on time.

If you average the result, then it's when you get that 1/10th of a frame of lag, but that would lead to thinking that there's some lag associated to each button press while this is absolutely false. I.e. even for fd 7, most of the interaction matches the experience with original hardware.

And even so, this would be in a worst case scenario, where the pcb would poll the switches during vblank. On the other hand, if the pcb would read input let's say in the middle of the frame, then fd 5 would be enough to match the pcb responsiveness, this means zero lag.

Unfortunately we don't know where each pcb polled input, so assuming the worst case scenario is the best we can do. We'd need to test GM against a real pcb to know the actual lag (lag, again, by jimmer's sense), but it should be equal or less than the one considered by using this method.

In the same way, the value that oomek provides, e.g. 4.08 ms for fd 9, is telling us the latest button press that GM can catch. … msg1694987

Re: Groovy MAME: Installation and quick configuration (2019 guide)

Added a note to the section about frame delay configuration.

Re: Groovy MAME: Installation and quick configuration (2019 guide)

GM 0.216 got a new option (as such) which should be enabled if you're importing a previous config. file (it's enabled by default):

Calamity wrote:

About the new -lowlatency option.

MAME now includes the new option -lowlatency (-lolat). This means that some of the modifications that have been part of GroovyMAME's low latency features are now officially included in MAME. The technical details are explained on MAMEdev's github site.

I'd like to thank Oomek for donating one of his prototype G.I.L.T devices for these tests that was essential to prove the effectiveness of this feature.

If you own a VRR monitor (either Freesync or G-sync), now official MAME's input latency will be exactly as low as GroovyMAME's, virtually matching original hardware behaviour in many cases. Unlike -frame_delay, -lowlatency has no performance penalty.

This new feature won't change input latency on GroovyMAME at all, compared to previous versions, since it was already included in GM before. You only need to make sure the option -lowlatency is enabled, which is by default in GM's generated ini. But take care to update at least your old mame.ini, because failing to have this option enabled will indeed cause a latency penalty since now this feature is optional, while before it was always on.

In the context of non-VRR monitors, the biggest part of input latency is caused by v-sync. VRR monitors don't need v-sync, so they're free of this problem. For this reason on VRR monitors, -lowlatency is enough to get latency as low as it gets.

On the other hand CRT screens and traditional LCDs require v-sync for acceptable results. The latency that's specific to frame buffering associated to v-sync can't be removed by the -lowlatency option. In order to remove it, in addition to -lowlatency you need to keep using -frame_delay, as usual. Now, the difference now is that unless you have -lowlatency enabled, -frame_delay won't have the desired effect, so please pay attention to your setup if you're upgrading.

In short, for low latency, use the following:

- VRR (Freesync or G-sync): official MAME -lowlatency
- CRT or traditional LCD: GroovyMAME -lowlatency -frame_delay #

For VRR, official MAME is simpler to use. You can achieve the same results on VRR with GroovyMAME too, but you need additional config, like this: GroovyMAME -monitor lcd -lowlatency -noautosync (or -nowaitvsync, notriplebuffer, nosyncrefresh). … msg1701937

Even if only for variable refresh rate LCD monitors (which will be the norm in a not-too-distant future, anyway), this is quite an event for MAME itself, which could never be taken too seriously up until now by any player who cared a damn due to the latency/input lag issue.

Congrats, Calamity!