5.2.2. Video Mode Maker: Generating video modes.
VMM is used to generate video mode lists in an automated way, for their use with CRT Emudriver. Although CRT Emudriver already installs a list of common video mode by default, you will probably want to customize it to better fit your particular monitor and set of emulators.
VMM is currently a console application, so it has no GUI. Using VMM is a simple task that consists on these steps:
1.- Do the configuration. This involves manually editing VMMaker.ini, ReslList.txt, and maybe MameMain.txt.
2.- Run VMMaker.exe (Run as administrator if you're in Windows 7).
Any further configuration can be done by repeating this process. Bear in mind that each time you run VMM, all existing modelines will be overwritten. Take care of this in case you had done manual adjustments to the current modelines.
VMM uses two sources of information as input for the list of video modes it will calculate:
- XML List: this is used specifically for the MAME/MESS/UME emulators. These can output all the native video modes for their emulated systems in .xml format. VMM can then use this information to automatically create the required video modes.
- Custom List (ReslList.txt): this is a list in plain text format which the user can freely customize, by adding or removing video modes that will be later created by VMM. Just be careful to follow the format and spacing.
Both sources can be used simultaneously, and an independent set of options applies to each of them (see below suffixes "_XML", "_custom"), so you can filter and rationalize the resulting list to your convenience.
VMM assigns the highest priority to the video modes from the Custom List, and relegates the ones coming from the XML list to lower priority. You can still promote one video mode from the XML list to high priority by adding its source game name to the MameMain.txt list. Priorities are important because usually VMM will need to prune the resulting modelist in order to get it to fit in the driver's memory. In this situation, low priority modes are dropped first.
Now we will discuss the different options in VMMaker.ini. You have samples for typical use cases in the Apendix B of this chapter. VMMaker.ini is divided itself into four main sections, and should be edited as follows:
- MameExe: use this option to enter the full path of your MAME/MESS/UME executable file. E.g.: MameExe = "c:\Emu\MAME\mame.exe". If you'd like to get video mode information simultaneously from MAME and MESS, use one of the existing combined builds (UME). This option is only required if GenerateXML is enabled.
- IniPath: use this option to enter de full path of your MAME .ini folder. E.g: IniPath = "c:\Emu\MAME\ini\". Mind the ending backslash! This option is only required if GenerateInis is enabled.
- ListFromXML: Use this option to enable video information being listed from an XML source. The information is extracted from the emulator program itself, which stores all the modelines used by the games it emulates in an .XML file. For this, you need a version of MAME/MESS/UME previously installed. Keep in mind that these video modes have been defined by the emulator's coders themselves, and could not be totally accurate depending on the emulation status for every particular game/system. For arcade games in general, there isn't currently a better video documentation source than MAME, anyway.
- GenerateXML: Enable this option to actually retrieve the XML file from MAME/MESS/UME. Because this is a slow process, it is generally fine to do it just once, and then disable this option so the next time you run VMM it can reuse the already generated XML file.
- OnlyListMain: By using this option, you can force VMM to only create the video modes from the games contained in MameMain.txt, when the XML file is processed. All other modes from the XML file will be discarded. This is useful in case you're only interested in emulating a few games.
- GenerateInis: enable this option if you want VMM to automatically configure MAME in a per-game basis -- it can create the .ini files the emulator uses for every game, so that you don't have to set every particular game's video options for the native video modes. This option is meant for official MAME. The use of individual .ini files has become obsolete since the development of GroovyMAME.
- MonitorHorizontal: enable this option if you want vertical games to be rotated so that you can run them on a horizontal monitor. Instead of their native resolution, a suitable rotated video mode will be calculated. Horizontal games will keep their native resolution. If this option is disabled, both horizontal and vertical games will keep their native resolution, meaning that you will need to physically rotate your monitor in order to display the vertical ones.
- RotatingDesktop: enable this option if you're planning to rotate Windows' desktop as well when you physically rotate your monitor. This option only affects the options applied to .ini files, in case these are created.
- VerticalAspect: by default, VMM will calculate the resolution of rotated vertical games so that it matches the correct aspect ratio, usually 4:3 (3:4 when rotated). Some users find the correct aspect too "skinny" and prefer a wider picture. This option allows enforcing any aspect ratio for rotated vertical games:
4:3 (keeps original aspect ratio)
3:3 (stretches to square format)
3:4 (stretches to full screen)
h:v (custom aspect ratio)
-MonitorType: Use this option to define the type of monitor in use (since CRT Emudriver is able to work with any type of monitor and not just 15-kHz ones), so that VMM generates the modelines properly for your monitor's specifications. The following presets are included in VMM:
- MonitorType = "GENERIC" Standard 15-kHz monitor (15.7 kHz)
- MonitorType = "NTSC" Standard 15-kHz-only NTSC CRT TVs
- MonitorType = "PAL" Standard 15-kHz-only PAL CRT TVs
- MonitorType = "CGA" Standard resolution "CGA" monitor (15.2-15.7 kHz)
- MonitorType = "EGA" Medium resolution "EGA" monitor (24.9 kHz)
- MonitorType = "VGA" High resolution "VGA" monitor (31.5 kHz)
- MonitorType = "MULTI" Multi-sync CRT PC monitors (54-82 kHz)
- MonitorType = "D9800" Wells Gardner D9800, D9400 (15-38 kHz)
- MonitorType = "D9200" Wells Gardner D9200 (15-38 kHz)
- MonitorType = "H9110" Hantarex MTC 9110 (15.6-16.7 kHz)
By default, MonitorType is set as "CUSTOM", and a sample monitor_specs line is provided, which should be good enough for the average 15 kHz arcade monitor and CRT TV. Notice that most CRT TVs are actually multi-standard. This means that they will support both PAL and NTSC signals. In this case you'd better leave the default configuration, instead of choosing any of the "PAL" or "NTSC" presets, which are only meant for TVs that require strictly standarized timings.
- monitor_specs_0-9: A more technical approach involves keeping the MonitorType line as "CUSTOM" and manually defining the monitor's specifications by editing the line monitor_specs_0. Though this is the way to get the best performance out of your particular monitor through CRT Emudriver, it requires proper technical knowledge of your monitor and a deeper understanding of how a CRT works, so it's aimed only at advanced users, therefore we'll explain the method in a separate subchapter here. Keep in mind, nevertheless, that this method will serve to also solve generalized problems regarding screen geometry and visible area which may appear after generating video modes with any of the monitor presets.
3) MODELINE GENERATOR
- TotalModes: This option defines to maximum number of video modes to be generated. By default it is set to 120, which is a safe value for all CRT Emudriver versions. Only the version based on Catalyst 6.5/32-bit allows up to 200 modes. Remind that Hyperspin frontend will fail to start if too many video modes are defined.
If processing both the XML and Custom Lists results in the TotalModes value being exceeded, VMM will need to prune the mode list, until it meets the TotalModes value. Discarded video modes are listed in the Droplist.txt output file after the process. The pruning process intends to be intelligent. Modes that are used by few games or are easily substituted for another one in the list with minor issues are dropped first. As explained above, modes from the Custom list have the highest priorty and should be dropped in the last place, as well as the ones belonging to games from MameMain.txt.
Being able to deal with huge mode lists has been crucial in the past. However, since the development of GroovyMAME, this is not a critical factor anymore.
The following group is presented as pairs of options, with the suffixes "_XML" and "_Custom". What you need to understand is that the "_XML"-ending options apply to the video modes from the XML List, while the "_custom"-ending options apply to the ones from the Custom List. This is very important because it allows using different criteria depending on the source.
- ModeTableMethod_XML / ModeTableMethod_Custom: these options define the method you want to use when creating the mode table. The values allowed here are the following:
0 = Static Table: video modes are generated keeping their original vertical refresh rate. This is the method you will usually apply to the modes from the Custom List and also to the XML List in case you use official MAME and .ini files per game.
1 = Dynamic Table: a table of dummy modes is created using the width and height native values while ignoring the vertical refresh. This method is intended to be applied to the XML List to create a suitable mode table for GroovyMAME. No .ini files are requiered in this case (remind to disable the CreateInis option.
2 = Magic Table: a table of "magic" resolutions is created, in the form 1234 x height, by ignoring the native width and refresh and only keeping the height. This method drastically reduces the size of the mode list. It's only supported by GroovyMAME under Windows XP (it won't work under Windows 7), and is intended as a workaround for the Hyperspin issue.
When using the Static Table method, care must be taken if you're defining two instances of a given resolution with different but close refresh rates (closer than 1 Hz). You may run into an issue because the operating system labels the refresh rate with an integer number. For this reason both modeline definitions will overlap. The traditional workaround has been incrementing the logical width of the video mode by one pixel for each refresh variant, and matching each game with the proper variant in its .ini file. VMM does this automatically for you automatically in order to avoid overlapping labels. Unfortunately this workaround no longer works in Windows 7, making the Static Table method mostly unusable for XML sources in practical cases. In this situation, the use of GroovyMAME combined with a Dynamic Table is the only reasonable approach. However, you will still need the Static Table method to deal with the video modes required by other emulators that don't manage refresh rates by themselves like GroovyMAME does. In these cases, you will need to define the video modes with their exact refresh rates in ReslList.txt, paying attention not to generate cases where the refresh rates would overlap as described above.
When using the Magic Table, GroovyMAME overwrites the dummy "1234" value with the native width of the emulated game, creating a genuine modeline with the required width. This is actually a hack and may work great in many systems while causing issues in a few. It is strongly recommended to use Direct3D instead of DirectDraw when using this method.
As an alternative to the Magic Table that is compatible with both Windows XP and 7, you can use "super" resolutions. This is a special case of Dynamic Table, where the native width is substituted by a super-wide resolution, usually 2560, meant to perform fractional stretching over the horizontal axis, while keeping the native height unmodified. Due to the nature of CRT monitors, provided a high enough horizontal resolution is used this method produces no visual artifacts. A special "ReslList - super.txt" file is provided with instructions to set up "super" resolutions. This method is becoming the rule in the emulation scene, driving the other ones into obsolescence.
- XresMin_XML / XresMin_Custom: This option simply sets a minimum value for the horizontal resolution. Lower values will be replaced by this one.
- YresMin_XML / YresMin_Custom: Idem but for the vertical resolution. This option is important in order to optimize your mode table. With standard arcade monitors and from a hardware point of view, vertical resolutions below 240 lines are totally equivalent to displaying the same resolution within a 240 line mode and adding black borders as padding above and below the active lines. For this reason, creating those resolutions is redundant and a waste of space in the mode list, so it is recommended to set this value to 240. However this is only true if you use an emulator that is smart enough to center the vertical resolution without stretching it (GroovyMAME is, and official MAME too when used with DirectDraw).
- YresRound_XML / YresRound_Custom: Use this option to optimize the resulting mode list. By rounding the height to the next defined multiple VMM will produce a more reasonable mode list, while keeping the visual features intact. These are the allowed values:
0 = Leave original value
1 = Round to next 2-multiple
2 = Round to next 4-multiple
3 = Round to next 8-multiple
4 = Round to next 16-multiple
Bear in mind that some of the values above can prevent common resolutions from being created. E.g. 800x600, when using 16-multiples won't be created as such, because 600 is not divisible by 16.
- DotClockMin: Use this option if your video card can't support low dotclocks. As a workaround, VMM will duplicate the horizontal resolution of the video mode, whenever the calculated modeline results in a dotclock under the value specified by this option. To make use of this you will need an emulator that is capable of integer scaling on the horizontal axis (any MAME build is). The value must be specified in MHz. E.g. DotClockMin = 7.010
- Iterations: This option allows increasing the accuracy of the resulting refresh by successive iterations of the modeline generator. Valid values are 0-5. To use this option, a valid look-up table of precalculated dotclocks is required. One sample of this table is provided for the Radeon 9250. Users of this card can benefit from the extra accuracy when using this option. For other cards, this option won't result in any improvement, so it's better to keep it disabled.
- DisplayName: This option allows VMM to point to the right device when creating modelines. Usually it will be "\\.\DISPLAY1", unless your system has more than one video card. If that is the case you will need to find out the display number that represents your target Radeon card and edit this option accordingly.
- DriverPath: This option sets the path to the driver installation files (".\Driver\" by default), in order to add the modeline definitions directly into the driver's .inf files, making it useful for cloning the current setup on further driver installations. Starting from Windows 7, digital signature is required for .inf files, making this feature obsolete.
UpdateDriver: This option is used in combination with DriverPath in order actually enable the driver's files update, as explained above. Same remarks apply.
- UpdateRegistry: By enabling this option you allow VMM to install the calculated modelines in the Windows registry. Default value is enabled. You can disable this option if you want to use VMM as a simple modeline calculator, without modifying your current setup.
- AnyCatalyst: By enabling this option you can force VMM to install the calculated modelines even with regular Catalyst drivers (non-CRT Emudriver).
The ReslList.txt file format consists in a simple list of video modes, in the form "width x height @ refresh label". You must respect the proper spacing just as shown below, otherwise the file parsing will fail:
## Samples ##
640 x 480 @ 30.000000 desktop1
1280 x1024 @ 60.000000 desktop2
256 x 224 @ 60.098475 superfam
Finally, you may want to edit the MameMain.txt file. VMM makes a selection among the whole XML source attending firstly to the games/drivers defined in the MameMain.txt file, which will get priority only after the modes defined in ReslList.txt.
MameMain.txt can be edited according to the user's preferences, so you can delete or add the games/drivers corresponding to the video modes you want by following the format (it uses MAME's romset/driver names), once you know them by way of MAME documentation. You can also use MameMain.txt in combination with the OnlyListMain option explained above, to filter out anything that's not in this list.
The entries in MameMain.txt as default have been chosen so that any relevant title gets it's video mode created, but the list is always susceptible of being modified. A sample of the expected format is shown below:
mustang, "NMK 1989"
snowbros, "Snow Bros"
bublbobl, "Bubble Bobble"