http://forum.arcadecontrols.com/index.p … 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!

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

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:

http://geedorah.com/eiusdemmodi/forum/v … .php?id=36

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

G.1) USAGE OF SCALING OPTIONS

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
noues
intoverscan

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
intoverscan

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

G.2) 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.3) 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 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

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.

F.1) SETTING THE BEST CRT RANGE

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:

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.

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

Notes:

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

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.

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.