1 (edited by Recap 2019-08-22 13:41:34)

Topic: Groovy MAME: Installation and quick configuration

This guide is obsolete. Click here for the 2019 version.


We've made this with two purposes -- helping to get Groovy MAME 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 Groovy MAME's official documentation.

Groovy MAME is also 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.172, being the first one adopting some work by Calamity as the first step to, perhaps, one day, getting the whole Switchres from Groovy MAME included into mainline. The present guide, given the transitional nature of the latest versions, has been made with Groovy MAME 0.170 in mind (*), being this also the last one to support Direct Draw. With the recent CRT Emudriver 2.0 and CRT Tools, the installation and configuration process has also been simplified and improved. Keep in mind that, with Groovy MAME 0.169 onwards, previous versions of VMM are not supported (it needs the video modes generated by the new CRT Tools), though you can use the new CRT Tools with the older CRT Emudriver version (for both, Windows XP and Windows 7/8); just make sure you generate a fresh video mode list with them.

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.

We believe it's better to use the "official" board at BYOAC to discuss anything Groovy MAME-related, but feel free to make posts here in this thread too. (Please, remember that we already have a thread for frontends discussion.)

(*) Read this post in order to know the major changes from 0.170 to 0.182 version. We recommend to have Groovy MAME updated as much as possible since it's improving with every Switchres version.

2 (edited by Recap 2016-06-13 21:26:59)

Re: Groovy MAME: Installation and quick configuration

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 both, MAME and Groovy MAME's files in their matching versions and according to the OS' spec. (32 or 64 bits). 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. Note: 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.

Important: Be aware that there exists a special build of Groovy MAME (64 bits) by Intealls which makes use of ASIO drivers in order to improve audio latency. If you have either, an ASIO- or an ASIO-4-All-compatible sound card (any on-board sound device with Realtek part from these years will likely do), it's recommended to generally use this build, even if further per-game configuration could be needed. Version 0.170 can be downloaded here. ASIO-4-All drivers must be previously installed (unless an ASIO-capable sound card is being used) -- download them from here and check Use off-line settings during the installation.

2. Create a directory for MAME in the target computer, say, C:\GROOVYMAME, and extract into it the content of MAME's compressed file. A file with the name mame64.exe (or mame.exe, for 32-bit versions) should be there -- delete it.

3. Extract the content of Groovy MAME's compressed file into the same directory -- a new mame64.exe file should be there. Right-click it, go to properties and give it Admin. privileges.

4. Create the following folders: 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.

5. Go to Windows Start button, click Run, and then type C:\GROOVYMAME\mame64.exe -cc in the command prompt window in order to create Groovy MAME's main configuration file mame.ini. (This file will have to be moved from C:\Windows\System32\ to C:\GROOVYMAME\ in the case it's created there.)

6. Choose a MAME-compatible frontend in order to be able to launch Groovy MAME without resorting to command line operation (check the internet to see what's better suited for your tastes keeping in mind the minimum screen resolution it requires to operate). Configure the frontend 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 MEWUI (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. 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

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.170's mame.ini 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

rompath                   roms;C:\ROM\MAME
hashpath                  hash
samplepath                samples
artpath                   artwork
ctrlrpath                 ctrlr
inipath                   .;ini
fontpath                  .
cheatpath                 cheat
crosshairpath             crosshair

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

hiscore_directory         hi

autosave                  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
sleep                     1
speed                     1.0
refreshspeed              0

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

artwork_crop              1
use_backdrops             0
use_overlays              0
use_bezels                0
use_cpanels               0
use_marquees              0

brightness                1.0
contrast                  1.0
gamma                     1.0
pause_brightness          0.65
effect                    none

antialias                 1
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

drc                       1
drc_use_c                 0
drc_log_uml               0
drc_log_native            0
cheat                     0
skip_gameinfo             0
uifont                    default
confirm_quit              0
ui_mouse                  0
autoboot_delay            2
console                   0

disable_hiscore_patch     0
disable_nagscreen_patch   1
disable_loading_patch     1

modeline_generation       1
monitor                   generic_15
orientation               horizontal
connector                 auto
interlace                 1
doublescan                1
cleanstretch              0
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

debugger                  auto
debugger_font             auto
debugger_font_size        0
watchdog                  0

multithreading            0
numprocessors             auto
bench                     0

video                     auto
numscreens                1
window                    0
maximize                  1
keepaspect                0
unevenstretch             0
waitvsync                 0

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

priority                  0
profile                   0

menu                      0

hwstretch                 0

hlsl_enable               0
hlslpath                  hlsl
hlsl_prescale_x           0
hlsl_prescale_y           0
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
curvature                 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_bright_scale     1.0
scanline_bright_offset    0.0
scanline_jitter           0.0
hum_bar_alpha             0.0
defocus                   1.0,0.0
converge_x                0.25,0.00,-0.25
converge_y                0.0,0.25,-0.25
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.4
offset                    0.0,0.0,0.0
scale                     0.95,0.95,0.95
power                     0.8,0.8,0.8
floor                     0.05,0.05,0.05
phosphor_life             0.4,0.4,0.4

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_length_scale       0.5
vector_length_ratio       500.0

bloom_blend_mode          0
bloom_scale               0.25
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.04
bloom_lvl6_weight         0.04
bloom_lvl7_weight         0.02
bloom_lvl8_weight         0.02
bloom_lvl9_weight         0.01
bloom_lvl10_weight        0.01

triplebuffer              0
full_screen_brightness    1.0
full_screen_contrast      1.0
full_screen_gamma         1.0

global_inputs             0
dual_lightgun             0

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                     d3d9ex

Groovy MAME 0.170 under Windows 7 can use Direct Draw, Direct 3-D 9 and Direct 3-D 9 Ex, being the latter the recommended API. 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. In order to use Direct 3-D 9 Ex, delete auto and type d3d9ex here, otherwise, Direct 3-D 9 will be generally picked.

The advantage of Direct 3-D 9 Ex over Direct 3-D 9 is that, unlike with the latter, there's no need to enable frame delay in order to force the frame latency to the minimum allowed by the driver and therefore avoid the dreaded frame queues present in the ATI video drivers when Direct 3-D is used, which add a lag of 2-3 frames.

For the case of the games using interlaced modes, Groovy MAME will automatically pick Direct Draw no matter what's been defined. This is intended as a workaround for Windows 7's design fault with interlaced modes (they are reported as having a halved refresh and synchronizing to these modes has the effect of halving the emulation speed -- Direct Draw bypasses this problem). In addition to that, Groovy MAME does also bypass Windows 7's inability to switch between progressive and interlaced modes under Direct Draw, so there's no need to manually make a mode change when using this API.

If the user wants to force Direct Draw or Direct 3-D 9 into a particular game/machine, the machinename.ini should have this line with ddraw or d3d instead of d3d9ex.

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

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. It's very important to remark that -triplebuffer needs the -multithreading option to be enabled in order to work -- unless you force -syncrefresh in mame.ini, Groovy MAME will try to enable -triplebuffer when required, regardless of the -multithreading option state, causing sound stuttering. So if you're experiencing sound stuttering when running the games designed for vertically-oriented monitors on horizontally-orientated monitors by way of rotating the picture, the most possible cause is Groovy MAME not being able to active -triplebuffer properly because -multithreading is disabled.

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.

4. multithreading            1

For -triplebuffer (Windows) to actually work as intended, -multithreading must be enabled first in mame.ini. This must be done manually as it is disabled by default for stability reasons (users of invasive frontends may get the emulator process killed).

The multi-threading feature in Groovy MAME is actually different to the one in mainline MAME (currently), being yet another of Groovy MAME's advantages over it. In mainline MAME -multithreading was added to improve performance by moving the window management (including rendering) to a second thread, making it asynchronous to the core emulation. This lack of synchronization causes well-known emulation bugs and indeed it's not recommended for a general usage. Groovy MAME's implementation, on the other hand, puts the focus on input responsiveness by separating input processing and rendering into different threads in order to avoid -waitvsync from locking input. Whether this has a real impact regarding input-lag reduction (for an up-to-date system) is still to be confirmed, though that could likely be the case. As long as -syncrefresh is in use, anyway, for the emulation side, it's exactly as if -multithreading was disabled -- as both threads run synchronized, the aforementioned bugs cannot happen, while the emulation performance gets the intended push-up if your system's CPU has more than one core.

5. disable_hiscore_patch     1

Set it to 0 in order to enable MK Champ's hiscore.diff. This is an unofficial feature to permanently save game score ranks in some games without non-volatile memory or support for it, by way of a HISCORE.DAT file. As it hacks the game's behaviour, emulation issues are prone to appear with it enabled.

6. disable_nagscreen_patch   1

Set it to 0 in order to enable MK Champ' patch to skip per-game emulation warning screens (unofficial feature).

7. disable_loading_patch     1

Set it to 0 in order to enable MK Champ' patch to skip per-game emulation loading screens (unofficial feature).

D )   C o n f i g u r i n g   G r o o v y   M A M E   A S I O

These are the instructions compiled and edited for convenience from Inteall's posts at BYOAC for the ASIO-related part of his build. Please, check his own thread for its genesis, development and discussion.

This alternative Groovy MAME build uses BASSASIO, which in turn uses ASIO to provide lower audio latency. I've gotten the best results with integrated cards. The result with discrete cards range from excellent to terrible. Should work on both XP and Windows 7/8/10. Note that for XP you really need a proper ASIO-capable card for decent performance. Games running at very inconsistent speeds will probably sound worse than with the other APIs.

Steps to getting things running:

Sound card with native ASIO driver: Configure the latency through its control panel and run the executable. You could also use Batool (64) to access the control panel.

No native ASIO driver:

- It's assumed ASIO-4-All has been previously installed as explained before.

- Start Groovy MAME ASIO and press ALT + Enter to run it in a window.

- In Windows' system tray, a green ASIO-4-All icon should show up. Click this and configure the sound card to be used. The settings pane should look something like the attachment (make sure to enable Allow Pull Mode). Try setting a latency of 96, and restart GM to try it out. If the sound is crackling continuously, with a game you know should run well, try a higher setting (you should be pleased with anything lower or equal to 256, but do never set it below 96).


- Required in mame.ini: -multithreading 1

- Don't run other applications, and try setting sleep 0 and priority 1 in mame.ini -- might help with very low latencies.

- If you run the emulator from the command line with -v (verbose enabled), you'll get an underrun/overrun counter at the bottom of the MAME log. The overruns/underruns should be hard to hear, but you can tweak a parameter for better results.


Re: Groovy MAME: Installation and quick configuration

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.


Re: Groovy MAME: Installation and quick configuration

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

F.1) Setting the best monitor specs

Different monitors require different definitions for the monitor's specifications in our system, and it's the monitor specs what determines overall screen geometry. Through Video Mode Maker, a definition of monitor specs 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 the monitor specs.

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 monitor specs line consists of, which is widely explained here. 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 monitor specs 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 for some reason 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.

F.2) Tuning up the screen geometry in a per-game basis

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. 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 to have a modeline already available in the 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 resolution instead, Groovy MAME will not use the vertical refresh attending Arcade OSD, but attending the emulator's request for that game, if v-sync is not disabled. The picture won't be scaled if it doesn't match the defined resolution (black borders and some shift will 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.

G )   E x t r a   t i p s

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

G.1) Improving performance on games with switching resolutions

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.

G.2) Forcing single scan on games with double-scanned graphics

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 hardware de-interlacing, this can only be achieved by installing a super wide resolution of 233 lines in this case, setting it through machinename.ini and the resolution command, and also setting cleanstretch 2.

(Note: From Groovy MAME 0.177 onwards, cleanstretch options are no longer used, so set -ues (unevenstretch 1) in machinename.ini. This is required so fractional stretching is forced. 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

Forgot to thank Cools for his own guide at http://forum.arcadeotaku.com

It was used as the base for this due to its popularity.


Re: Groovy MAME: Installation and quick configuration

You're more than welcome. I've been meaning to update for Windows 7 but haven't had the time, saved me a job ;) Great work!


Re: Groovy MAME: Installation and quick configuration

Starting with GM 0.167, some improvements have been done to the frame delay mechanism that make it more stable.

GroovyMAME 0.167 is out (Switchres v0.015j).

What's new in SwitchRes v0.015j

- Direct3D9ex support [koopah, intealls] (new option: -video d3d9ex): now GroovyMAME supports Direct3D9ex, which is present in all versions of Windows starting with Vista. This allows the application to take control of the frame latency and force it to the minimum allowed by the driver, avoiding the dreaded frame queues. This is specially useful in the situations where frame_delay can't be used reliably without tearing (LCDs, high resolutions). Besides, Direct3D9ex seems to perform better for certain hardware (Nvidia, Intel), so it may be preferred to plain Direct3D9 in general.

- Frame delay (improved) [intealls, Calamity]: now frame_delay polls the video driver for absolute scanline values, totally bypassing the default vertical synchronization functions. Some of the advantages are:

  · Improved stability of the vertical synchronization mechanism, that finally makes it possible to extend GroovyMAME's audio/video synchronization to the frame delay use case.
  · Awareness of the raster position and notification of missed retraces.
  · Allows for anticipating the vertical retrace accurately (see vsync_offset, below).

- Vsync offset [intealls] (new option: -vsync_offset): forces render to happen a certain number of lines before the vertical blank (e.g. -vsync_offset 200). At high resolutions (LCD, etc.), the time it takes the GPU to scale a frame starts being longer than the blanking period itself. This is specially true when HLSL is used. This appears as 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, even on LCDs with frame_delay and HLSL enabled. In practice, you need a fairly fast 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. Notice that you'll need to lower your frame_delay value proportionally to the amount of lines you set in -vsync_offset.

There are some important implications to these changes also for CRT users. Now it's no longer necessary to enable frame delay in order to bypass the frame queue. Just switching to Direct3D9ex already removes the frame queue in an ortodox way. This frame queue is the most important source of input latency in modern systems. Notice that Direct3D9ex is not available in Windows XP.

There's still one remaining frame of latency that can't be removed through Direct3D9ex alone: the one caused by double buffering. The reason for frame delay is to remove this last frame of latency and achieve next frame input response, matching real hardware behaviour.

Because the frame queue can usually involve 3 frames of lag or more, most users will find it good enough to simply remove it by switching to Direct3D9ex, as compared to the relatively minor improvement and important hassle of adjusting frame delay in a per game basis. However, the next frame response nirvana is reserved to frame delay users. Be aware that you'll need a powerful machine in order to reliably apply high values of frame delay.

For Windows XP users, however, Direct3D9ex is not an option, so you'll need to stick with Direct3D + frame delay in order to remove the frame queue + the last frame due to double buffering, as we did before and is explained in Recap's guide above.


Re: Groovy MAME: Installation and quick configuration

Nice. Thanks to everyone involved. I'll wait a couple of versions before properly updating the guide just in case, but does this still apply?

Groovy MAME will choose Direct 3-D when leaving this option in auto except for the case of the games using interlaced modes, where Groovy MAME will automatically pick Direct Draw.


Re: Groovy MAME: Installation and quick configuration

Recap wrote:



Yes, it's still the same. You need to force -video d3d9ex specifically. Interlaced modes still require DirectDraw by now, although this will change in the future.


Re: Groovy MAME: Installation and quick configuration

Calamity wrote:


That is so nice to hear... you are a true arcade lover... :) big thumbs for this.


Re: Groovy MAME: Installation and quick configuration

Guide updated with the recent changes in both, Groovy MAME and VMM. I've also added a section for geometry tweaking.


Re: Groovy MAME: Installation and quick configuration

Updated again to add Intealls' Groovy MAME build with ASIO/ASIO-4-All compatibility and a mention of the drawback of using super resolutions against the native mode (check E. Per-game configuration, 1. Resolution).

14 (edited by demonius 2016-05-25 08:19:40)

Re: Groovy MAME: Installation and quick configuration

Hi Everyone. This is miy first post and my first time with groovymame.  I downloaded groovy mame 0.171 Asioall  and I started to configure everything. I have a tv crt Ati Radeon 4350 and cable scart vga-rgb. I have two questions.

1) can someone confirm that this parameters of mame ini which I configured are correct?

1. video                     d3d9ex

2. orientation               horizontal   

3a. syncrefresh              0               

3b. triplebuffer              0             

4. disable_hiscore_patch     1

5. disable_nagscreen_patch   1

6. disable_loading_patch     1

7.resolution                        2560x0 -cleanstretch 2.

2) I read that for the case of the games using interlaced modes, Groovy MAME will automatically pick Direct Draw no matter what's been defined. But how can work this now that in the mame 0.171 there is no more Direct Draw ?

Thank you every much


Re: Groovy MAME: Installation and quick configuration

That's an aspect Calamity is working on currently, I believe. The guide is for GM 0.170. Many changes are expected to come, little by little.

As for the rest, those are mostly "correct" depending on what you want to emulate and how. For games using vertically-mounted monitors you'll need to change the -orientation as explained if you're indeed using a vertically-mounted monitor. The hi-score patch, I believe, was removed from 0.171 onwards.

Edited a bit the F.2 chapter, by the way. You must not unlock V-freq in A-OSD when just making porch changes.

16 (edited by Recap 2017-02-07 11:50:26)

Re: Groovy MAME: Installation and quick configuration

Groovy MAME 0.182/Switchres 0.016 Final has been released by Calamity this past week and it's a good moment to update this guide with the changes since version 0.170 -- dynamic mode switching, for instance, was improved in a recent version (you shouldn't notice the desktop on the background anymore). But particularly because mainline MAME now has this:

Updated PortAudio library and added audio output module. [inte alls]
* Provides low-latency audio output on Windows 7 or later and Linux.

This means ASIO/ASIO-4-All builds are no longer necessary for low audio latency, since Port Audio options should get equally good results. It's being dicussed (for now) in this thread at BYOAC:

http://forum.arcadecontrols.com/index.p … msg1601757

So use it to get hints on how to configure Port Audio options.

Nevertheless, I'm not properly updating this guide for now, so here are the other changes you must be aware of if you're using this for configuring 0.182:

- Direct 3-D 9 Ex compatibility is only available in a separate build downloadable as groovymame64_0182.016_final_d3dex.7z, and with it, you must now type video d3d instead of video d3d9ex for usage of this API's Ex version, which is still the recommended one (unless you're on WIN XP). Direct Draw is no longer supported.

- The maximum value for frame delay is 8.

- Clean stretch options are no longer used. Integer scaling was added to mainline MAME by Calamity himself in 0.172:

* Moved -unevenstretch option to core renderer.
   -unevenstretch:   fractional stretching (default)
   -nounevenstretch: integer scaling

* Added new options to core renderer:

- Directly related to that, there's a new option, super_width, which defines the width that triggers the unevenstretchx option, used for super resolutions. The default value is 2560.

- There's no use for the multithreading setting anymore either, since GM sets it automatically now.

The thread for Groovy MAME 0.182/Switchres 0.016 Final is this, in case you want to check all the changes and their evolution:

http://forum.arcadecontrols.com/index.p … 83290.html

Though the guide hasn't been updated with these changes, I did add a final section for specific cases which will get more tips/examples with the time.