Introducing MAME 2003-Plus: a high-performance libretro arcade emulator

In Summer 2018, RetroArch added MAME 2003-Plus to the arcade section of its Core Updater. MAME 2003-Plus is a new arcade emulator core which prioritizes 1) usability and frontend integration, 2) performance, and 3) compatibility across the range of libretro-supported platforms including mobile devices, single board computers, and consoles. Unlike other libretro MAME cores which remain fixed at one MAME version, MAME 2003-Plus is actively backporting more recent game drivers and features.

MAME 2003-Plus implements libretro functionality like savestates and netplay when supported by the underlying MAME driver. The core currently has partial support for the RetroArch “Run Ahead” input latency reduction feature when Run Ahead is set to Second Instance — our goal is to support Run Ahead fully, as discussed later in this post.

dynagearddp3a

Newly-supported games include Dyna Gears and DoDonPachi Dai-Ou-Jou

MAME 2003-Plus is part of a lineage of codebase forks and ports: this core was forked from MAME 2003, which is itself derived from Xmame 0.78, the X11/Unix port of MAME 0.78. In addition to the games supported by MAME 2003, MAME 2003-Plus contributors have backported new drivers and substantial bugfixes for several hundred additional games.

New and fixed games

Bubble Bobble: Lost Cave

Screenshot of Bubble Bobble: Lost Cave, a hacked romset that arcadez backported to MAME 2003-Plus from MAME 0.202.

There is a long tradition in arcade emulation of producing platform-specific and performance-optimized MAME builds. This core was first established when arcadez began adding games that were not available in MAME 0.78 to a new fork of the existing MAME 2003 emulator. In addition to contributions from arcadez, the core has also benefited from the contributions of new and veteran MAME hackers. The most current list of new and fixed games can be found in the CHANGELOG.

Libretro integration and usability

One of the other things that makes MAME 2003-Plus distinct from the other libretro MAME cores is an emphasis on integration between MAME 2003-Plus and the libretro API. For example, there is full support for remapping player controls in the libretro frontend rather than requiring users use the legacy MAME input binding system from standalone MAME.

MAME 2003-Plus also strives to be as easy to start working with as possible. For example, this core incorporates a number of NVRAM “bootstraps” that pre-configure games with sensible default internal settings. That means in MAME 2003-Plus, Mortal Kombat 2 is configured with an appropriate volume when first launched rather than requiring use of the Service Menu. Another one of the games which benefit from an NVRAM bootstrap is Lunar Lander, which uses the bootstrap to avoid requiring the user to complete a Service Mode reset process before it is playable the first time.

Building correct romsets

While more than 95% of MAME 2003-Plus romsets are identical to MAME 2003 and MAME 0.78 romsets and can be used as-is, new and fixed games require romsets that are built for use with this core. Unless you are already sure that you have a romset collection that is correctly built for MAME 2003-Plus, you can consult the official docs for instructions on how to rebuild and verify your collection by using ClrMamePro.

As detailed in the building romset docs linked above, a ClrMamePro-compatible XML DAT file is maintained in the MAME 2003-Plus repository for users to download. One of the new features added to core also allows users to generate their own DAT via the MAME Menu. Generating a DAT ensures that it is an exact match for the version of the core that you are using.

screenshot 2018-10-28 13 30 23

Getting started with MAME 2003-Plus

  • RetroArch: MAME 2003-Plus can be installed from the RetroArch buildbot via the Core Updater.
  • RetroPie: MAME 2003-Plus can be installed in RetroPie in the Experimental section of the RetroPie Setup tool.

Documentation for this core can be found in the libretro docs.

Feature highlights

Content-aware core options

Because MAME 2003-Plus supports more than 4,000 games, there are a number of core options which only apply to a subset of its library. For example, there are several options to configure vector displays which have no effect for games with any other kind of display. MAME 2003-Plus only presents core options to the frontend that are relevant to the game that is currently loaded — those vector options only appear when a vector game is currently loaded.

Alternate CD Soundtrack Support

The NES Classic Mini and the SNES Classic Mini have an active hack and homebrew community which helped make MAME 2003-Plus and other libretro cores available on that hardware. Thanks to gpstar, KMFDManic, and others in that community, MAME 2003-Plus supports alternate soundtracks for several popular arcade titles that were also released in other formats with high quality audio soundtracks.

Out Run snapshot

These alternate soundtracks are enabled by first placing the appropriate audio sample pack within the mame2003-plus subdirectory of the libretro system path, and then activating the Use CD Soundtrack core option.

  • Double Dragon
  • Final Fight
  • Mortal Kombat
  • Michael Jackson’s Moonwalker
  • NBA Jam
  • Out Run

KMFDManic created videos demonstrating the alternate soundtracks:

Final Fight, Mortal Kombat, and NBA Jam

Out Run

Content-aware control names

In the same way that content-aware core options only appear when they are relevant to the current game, MAME 2003-Plus has added support for content-aware control names. In other words, when remapping Street Fighter 2 controls, the libretro frontend can display the control names that were printed on the real arcade control panel like Jump, Strong Punch and Forward Kick instead of a generic labels like Up, Button 1, Button 2, etc.

sf2-content-aware-controls

Street Fighter 2 displays the proper names for controls like Jump, Strong Punch, and Forward Kick.

Because our support for control names is relatively new and is derived from the third-party controls.dat project, control names need to be verified by a human being before they are activated. As of October 2018, dozens of games have these active control names, but hundreds more need to be double-checked before being enabled. Coders, and users who are willing to learn basic github commands, are invited to join in this effort as volunteers!

4-way joystick simulation

4-way joysticks are an essential aspect of the gameplay for many iconic arcade titles including games like Donkey Kong, Pac-Man, and Q-Bert. Because modern joysticks generally use 8-way designs, it is usually impossible to play these games well without special hardware. MAME 2003-Plus includes a core option to simulate 4-way joysticks. When enabled, this logic analyzes input from 8-way digital joysticks in order to render its position as if the joystick had a 4-way design. This simulation is not the same as using a real 4-way joystick, but it can make a significant improvement to playability.

qbert

Q-Bert is one of the many classic arcade games intended for a 4-way joystick.

Help needed!

MAME 2003-Plus is fortunate to have a small but active group of developers making contributions. However, there are several important opportunities to improve MAME 2003-Plus and its integration with the libretro API that remain to be addressed. Coders interested in working on these issues are very welcome to introduce themselves in the github issue tracker or in the #programming channel of the libretro Discord server.

For those who are not able to contribute code to these issues, crowd-sourced “bounties” are available that allow folks to donate to a pool of funds which is awarded to the coder who can complete the project. If you find yourself enjoying MAME 2003-Plus, please consider making a donation in any amount to one of the open bounties.

Analog controller support

Currently MAME 2003-Plus only supports analog controls in RetroArch by virtue of the fact that RetroArch passes on some analog input data to the core regardless of whether the core has implemented the analog interface. It is out-of-spec behavior and it also doesn’t encompass the full analog functionality of the libretro analog controls API. This bounty entails implementing that analog API. Contribute to the bounty or read the corresponding github issue.

Lightgun support

Because MAME 2003-Plus does not yet implement the relatively new libretro lightgun API, the core currently supports lightguns only if they are configured to emulate a mouse. This bounty entails implementing the libretro lightgun API. Contribute to the bounty or read the corresponding github issue.

Improvements to “Run Ahead” support

Every game has a certain built-in amount of input lag: some react on the next displayed frame and others can take 2, 3, or even more frames before an action on the controls gets rendered on screen. Run Ahead feature calculates the frames as fast as possible in the background to “rollback” the action as close as possible to the input command requested. MAME 2003-Plus has underlying support for Run Ahead but several bugs have been reported which prevent the feature from working as intended. Contribute to the bounty or read the corresponding github issue.

Other current bounties

Gambatte Progress Report

Written by J.D. G. Leaver

Gambatte Updates

Palette Additions

The Gambatte core has long been able to colourise greyscale Game Boy games using the default built-in palettes of the Game Boy Color:

Thanks to the assimilation of original work by [TRIFORCE89](https://github.com/TRIFORCE89/Gambatte-Core), we now also have access to the 32 default palettes of the Super Game Boy:

To complete the set, three additional palettes have been created to simulate the display characteristics of the various Game Boy hardware revisions: DMG, Pocket and Light. You want pea soup green? You got it!

All available palettes may be cycled via the usual ‘Internal Palette’ core option. Better still, the automatic Game Boy colorisation setting has been updated to automagically select the ‘best’ (most colourful/appropriate) palette for each game, using an internal database with the following order of preference:

1. Game-specific Super Game Boy palette, if defined and more colorful than game-specific Game Boy Color palette.

2. Game-specific Game Boy Color palette, if defined.

3. Game-specific Super Game Boy palette, if defined.

4. Palette specified by ‘Internal Palette’ core option.

(Of course, automatic selection may be overridden to force the use of either Game Boy Color or Super Game Boy palettes, or any specific palette that is desired)

Colour Correction Improvements

Game Boy Color games are designed to be viewed on a dim, low contrast LCD panel. Transfer these games to a modern high quality display and a proliferation of over-saturated colours will assault your eyeballs.

The Gambatte core has a long standing ‘Color correction’ option which tries to improve the generated image. This works after a fashion, but it tends to make everything too dark and has some unpleasant colour mangling side effects (e.g. it give Pikachu an orange perma-tan). Fortunately, the mighty Pokefan531 (https://forums.libretro.com/t/real-gba-and-ds-phat-colors/1540/159) provides a much better solution via an external gbc-color shader (https://github.com/libretro/glsl-shaders/blob/master/handheld/gbc-color.glslp). Now this same functionality has been added to the core itself.

Setting the new ‘Color correction mode’ core option to ‘accurate’ enables the Pokefan531 ‘gold standard’ colour correction method. The old Gambatte default can still be used by setting the mode to ‘fast’ (this slightly reduces CPU load and so may be useful on garbage-tier hardware – although the ‘accurate’ method is confirmed to run at full speed even on an o3DS). Here are some screenshots showing the difference in output image quality:

Care has also been taken to ensure that colour correction is only applied when appropriate. The new Super Game Boy and hardware-mimicking GB DMG/Pocket/Light palettes are intended for display on a standard television, *not* on a Game Boy Color LCD panel, and attempting to ‘correct’ them is a mistake. The ‘Color correction’ core option is therefore no longer a simple toggle: it may now be set to ‘GBC only’, which disables correction unless explicitly running a Game Boy Color game or using a Game Boy Color palette. (Of course, if you *want* broken Super Game Boy palettes, you can change the setting to ‘always’…)

These updates, along with the improvements to automatic colourisation, should make the core much easier to work with. Instead of generating core/shader overrides to deal with some games running in colour, and some not, you can now essentially set the following:

– GB Colorization: auto

– Internal Palette: GB – DMG/Pocket (or whatever)

– Color correction: GBC only

– Color correction mode: accurate

– Emulated hardware (restart): Auto

…and pretty much every game will look correct.

Dark Filter (a.k.a. Eye Saver Mode)

In addition to having over-saturated colours, it is not uncommon for games targeting early non-backlit handheld systems to make use of white backgrounds. While these look fine on original hardware, they are simply too bright when viewed on a modern backlit display. Staring at a strong blue-spectrum backlight is a recognised cause of asthenopic symptoms. These games are a health hazard!

On most platforms, this can be mitigated easily and effectively by the use of an appropriate LCD shader. Indeed, the simpletex_lcd shader (https://github.com/libretro/glsl-shaders/blob/master/handheld/simpletex_lcd.glslp) was written for this express purpose:

Unfortunately, shaders are not always an option: weak hardware may not be able to run them at full speed, and devices like the 3DS have no shader support whatsoever…

A more inclusive solution has therefore been added to the Gambatte core in the form of an adjustable ‘dark filter’. This is somewhat analogous to the filtering used in Nintendo Virtual Console titles, only less awful. Instead of a uniform brightness reduction, the ‘darkening’ is roughly proportional to pixel luminosity; this gets rid of harsh glare without (completely) butchering image quality.

The filter may be enabled by setting the new ‘Dark Filter Level’ core option from 5-50%. Here are some screenshots showing the effect at 30%:

Give it a try – your eyes will thank you!

Reicast Libretro and Reicast OIT Libretro merged into one! What you need to know…

Flyinghead has succeeded in merging both renderers into one. As a result, we no longer require a separate core for Reicast OIT, and there will be only one Reicast core from now on, simply called Reicast Libretro.

Recommendations

Moving forward, we recommend that you remove the Reicast OIT Libretro core from your cores directory, and leave only the regular Reicast Libretro core instead. This file should be called reicast_oit_libretro.{so/dll/dylib}. You can also remove the core info file that exists for it inside your Core Info directory. We have already proceeded to remove these files from our buildbot, but these files will be left lingering in existing installations unfortunately, necessitating this manual cleanup by the user.

So how do you switch between OIT and non-OIT now?


By default, Reicast Libretro will boot in non-OIT mode. You can tell if this is the case by going to Quick Menu -> Options and checking the ‘Alpha sorting’ option. If it’s set to ‘Per-triangle’ or ‘Per-strip’, the non-OIT GL2/GL3 renderer is used. You can use OIT mode by setting it to ‘per-pixel’ and then restarting the core.

Make sure that just like before, OIT mode (per-pixel accuracy) requires a video card that has OpenGL 4.3 support. Be aware that OIT mode is also much more GPU intensive than either per-strip or per-triangle alpha sorting. You might really need a good discrete GPU in order to be able to play this at decent speeds.

For which platforms is OIT mode (per-pixel alpha sorting) available?

It should be available for both Windows and Linux builds. macOS only supports OpenGL up to version 4.1, so per-pixel alpha sorting has to be excluded from this version unfortunately (since it requires GL 4.3).