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](, 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 ( provides a much better solution via an external gbc-color shader ( 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 ( 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.


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

Core Updates Summary and more Switch updates – October 2018

RetroArch Switch NSP

We now provide an NSP file for Switch straight from our Download page. The main reasons for using this are:

  • Being able to launch RetroArch straight from the main menu instead of having to boot Hbmenu first.
  • The Mupen64plus core requires more memory to be allocated than Hbmenu currently allows for. Mupen64plus will only work through the NSP file.

You can grab this from our Downloads page here.

Please be aware of the following disclaimer that should pop up before you use this:


New Switch cores! 49 Cores now!

Just a few days after launch, we already have a few new cores for the Nintendo Switch available for Nintendo Switch! You can grab these new cores by going to ‘Online Updater’ -> ‘Update Cores’ from within RetroArch, and downloading them one by one.

Let’s quickly run through some of them:


This is an early port of Mupen64 Plus for the libnx Switch port! Please be aware of the following:

  1. You will need to install RetroArch NSP and boot it straight from the main menu in order to be able to use this core. Mupen64plus requires more memory to be allocated than Hbmenu allows for.
  2. The framerate right now is not great. This is as a result of there being no dynamic recompiler right now, it just uses a cached interpreter core instead.

NOTE: Everybody is completely aware of the lacking performance of the current Mupen64plus. This is simply a proof of concept for now. Remember, once this bounty (which has amassed so far an amazing $1K+ in little over a week) is finally completed, most games will be running at fullspeed effortlessly on Switch with this emulator!

What this core illustrates is that libretro GL works fine on RetroArch Switch. You can expect to see more libretro GL cores being ported over to Switch in the near future. We are excited for what the future holds over this!

Mr. Boom

This is a great homebrew Bomberman clone made by franck. Up to 8 players can play locally, and you can even setup AI bots that will play against you in either singleplayer mode or multiplayer mode. This should be a perfect fit for the Switch with one Joy Con doubling as two controllers.

GW – Game & Watch

This is a Game & Watch simulator. It runs simulators converted from source code for the games available at MADrigal. Each simulator is converted with pas2lua, which was written specifically for this purpose, and uses bstree, which was also specifically written to obfuscate the generated Lua source code as per MADrigal’s request.

For more info, read this article here.

This core is courtesy of leiradel, who personally ported this over to Libretro.


81 is a port of the EightyOne (a.k.a. THE Sinclair Emulator) to libretro.

EightyOne emulates a number of ZX80, ZX81, clones, and other computers based on the same hardware:

* Sinclair ZX80
* Sinclair ZX81
* Timex TS1000
* Timex TS1500
* Lambda 8300
* Ringo R470
* MicroDigital TK85
* Jupiter ACE

However, 81-libretro only emulates the Sinclair ZX81 with 16Kb RAM for now. Other machines will be added as time permits. Push requests are welcome.

The port correctly loads and runs some many games I have around in the p format. tzx format is also supported.

EightyOne also emulates some ZX Spectrum machines, but those were left out of this core on purpose. For a ZX Spectrum core for libretro, see the Fuse core.

This core is courtesy of leiradel, who personally ported this over to Libretro.


This is a ZX Spectrum emulator.

For more info, read this article here.

This core is courtesy of leiradel, who personally ported this over to Libretro.

FB Alpha 2012 Neo Geo for Wii – Virtual Memory support!

Wiimpathy has now added Virtual Memory support for the Nintendo Wii! Finally, those bigger Neo Geo ROMs that were previously impossible to load on RetroArch Wii can finally be played with FBAlpha 2012 Neo Geo core!

Here are some notes left behind by Wiimpathy:

It uses the Wii NAND flash as virtual memory. The games also have to be converted/decrypted first to cache files with a PC program called romcnv.
This program is a modified version of romcnv used for MVS2PSP.
Romcnv binaries:
Romcnv Source:

Note that a few games(SNK Vs Capcom PCB for example) are still too large with this method.

Dosbox SVN – Dynarec on 32bit Windows/Linux and 32bit Android

radius has done extensive work on a new Dosbox libretro core. The dynarec has now been made to work on the following platforms:

  1. 32bit Windows/Linux versions
  2. 32bit Android versions

You can now play fairly modernish games like Duke Nukem 3D (from an MS-DOS perspective) on Dosbox at fullspeed!

But there is more! There is even MIDI playback implemented, and netplay works via IPX.


Last time we reported on Reicast, we had full keyboard support implemented which was already hot on the heels of full multiplayer online support with zero network configuration. Since then, flyinghead has not been exactly sitting still. An overview of the progress that has been made since:

  1. Lightgun emulation support (House of the Dead 2 (US and EU), Confidential Mission (EU), and Death Crimson 2 (JP) all confirmed working)
  2. Various crucial graphics bugs have been fixed on both Android and ARM Linux. FMVs should no longer show a black screen and Soul Calibur’s characters should no longer be black (due to high quality textures not being rendered).
  3. Threaded rendering mode’s stability has been further increased.
  4. A bug existed that caused white lines on the top and right side of the screen. Various games exhibited this. This has now been fixed.
  5. Further improved CHD image support.

The next thing flyinghead is planning to do is merging both Reicast and Reicast OIT into one, so that we no longer need to have two separate renderers/cores!