Libretro/RetroArch Progress Report/Update – November 2018

Libretro Team

RetroArch Switch nightlies now have overclocking support!

RetroArch for Nintendo Switch now has built-in overclocking support! Download the latest nightlies here –

http://buildbot.libretro.com/nightly/nintendo/switch/libnx/

There are 3 “Overclocking” and 3 Underclocking options.

On exit, RetroArch will restore the default system clock.
On docking, RetroArch will restore chosen clock (same with undock)
On focus loss, RetroArch will restore the default system clocks.
On focus gain, RetroArch will restore the chosen clock.

Some general performance hints:

  • Turn ‘Threaded Video’ on.
  • PSX should be fullspeed for nearly anything but a few ROM’s with 1.5GHz. Often, Boost mode should be enough.
  • Mupen64Plus needs a bit more juice for most games. In addition, turn off framebuffer emulation in the core settings.

Beetle PSX HW – Improvements to PGXP and better UV offset calculations for higher resolutions

You can see in this screenshot that the sprite to the right is sliced and has a vertical black line. Issues like these have been fixed uniformly now across software rendering, Vulkan and OpenGL. They would happen when upscaling internally at higher resolutions.

iCatButler has improved many aspects of PGXP (mainly to do with ‘memory + CPU’ option), and he has also fixed some longstanding issues to do with how sprites are rendered at higher internal resolutions. Line artefacts should be considerably reduced/eliminated as a result.

Below follows an explanation by the author:

There was already a sub-texel offset applied to all the base UVs which was causing it to sample out of bounds on 2D quads regardless of the UV orientation (in hardware the error was only when the UVs were flipped).

I’ve changed it so this offset is shrunk as the scaling factor increases, which solves the problem for positive UV/XY derivatives and allows us to use the same code from the hardware renderers to fix flipped UVs.

Here is a summary of the changes made:

  • Add PGXP calls for instructions that were previously missed. Should improve support for games like Croc, MGS, Alundra 2 and others that rely on CPU instructions for vertex handling.
  • Calculate and apply offset for quads with flipped UVs earlier.
  • Reduce offsets applied in software renderer as resolution scaling increases (fixes line artefacts).
  • Calculate UV limits used for filtering earlier and pass these to the individual renderers.

NOTE: Despite the aforementioned improvements, we still find that PGXP option ‘memory only’ generally tends to be the less bug-prone solution. It’s also considerably less CPU intensive, so always keep that in mind.

Cannonball – 120Hz mode!

CannonBall, the core running an improved OutRun Engine, has now analog axis and triggers support alongside a new 120Hz mode.

G-sync seems to react poorly with it though, so be sure to disable it if you experience audio clicks or skipped frames.

Supermodel repository coming soon!

The Supermodel repository is going to be committed to Github soon. From there, we expect that we will get it in working order over the span of a week.

It will be a good Christmas this year for RetroArch fans that love the old Sega arcade games. In less than a year, Reicast Libretro has made incredible strides for arcade emulation thanks to the efforts of flyinghead, and soon Sega Model 3 will be in the bag as well!

NOTE: Supermodel will be an OpenGL-only core. No Vulkan or Direct3D 11 renderer exists for this emulator.

RetroArch 1.7.6 coming soon!

There are several big things brewing in the background, most of them done by natinusula. They are mostly UI-oriented.

Natinusula is working on a fancy widgets UI layer for RetroArch. This will allow us to show UI elements onscreen while the game is running. It will be far more advanced than basic simple text which is all the OSD layer in RetroArch is currently capable of displaying.

We don’t know yet if this will make the cut for 1.7.6, but we can certainly try! On top of that, natinusula has been working hard on the Ozone menu driver. Some of the things that remain to be done there is better scaling for resolutions beyond 1080p, touch/mouse integration, and thumbnails. It is our hope that once this menu driver is in a solid shape, we can replace the current MaterialUI menu for Android/iOS with this one.

Again, we have to preface this by saying that we don’t know if any of this can be achieved for the 1.7.6 release, but it is certainly something that is being prepared and it will eventually arrive in RetroArch anyway. Rome wasn’t built in a day!

What is definitely coming up, is the following:

  • Resolution selection (for Windows only right now, X11 support coming soon).
  • Will remember window position/size (for Windows only right now).
  • Linux ALSA MIDI driver.
  • Vulkan: Bugfix – ‘secondary screen in overlays not working’.
  • You can individually decide whether frame count, FPS and memory information is being shown.
  • Metal: Now supports rotation.
  • Wayland: Screensaver inhibit support.
  • F3 hotkey toggles FPS counter.

BeetleDC Libretro Atomiswave support!

Libretro Team

Thanks to flyinghead, BeetleDC Libretro has now gained Sammy Atomiswave support! Sammy Atomiswave was an arcade system board based on the Dreamcast/Sega NAOMI hardware. A lot of SNK Playmore’s flagship games transitioned from the ageing Neo-Geo hardware to the much more modern Naomi-based hardware, such as Samurai Shodown, King of Fighters, Metal Slug and so on.

Both MAME ROMs and Demul-compatible roms should work. Note that as of right now, only a limited selection of Atomiswave games work. More will be added later today/tomorrow.

Here is a sampling of some of the games that already work. Shown here are Guilty Gear Isuka, Guilty Gear X, and Metal Slug 6.


BeetleDC Libretro NAOMI and MAME ROM support!

Libretro Team

Flyinghead is adding MAME ROM support to the arcade side of BeetleDC Libretro.

Here is what has currently been implemented:

  • NAOMI M1 cartridge support
  • NAOMI M2 cartridge support
  • NAOMI M4 cartridge support

Things you need to know

  • Right now, only non-merged romsets work. A merged rom is a ROM without parent, it contains all the files needed.
  • NAOMI M4 cartridges require a special BIOS file to be put inside your System directory. The M4 bios should be in a “naomi.zip” file in the BIOS folder (/dc ). The file in specific which hsould be inside that zip file is called ‘epr-21576h.ic27’.

Other important additions/changes

  • in the past, NAOMI games would only work with BeetleDC Libretro if you loaded .lst files. .lst files are no longer necessary now. You should be able to run an arcade game with BeetleDC Libretro using the plain .bin/.dat file instead now. So theoretically it should now be capable of just loading Demul-compatible ROMs instead.
  • Ring Out 4×4 now allows for up to 4 player support due to adding dual I/O board support for this game.

What are the list of MAME ROMs that are compatible?

You can check the entries inside this file here –

https://github.com/libretro/beetle-dc/blob/master/core/hw/naomi/naomi_roms.h

Out of these games, nearly all should work except for Samba De Amigo right now.

What’s planned/next?

  • Sammy Atomiswave MAME ROM support
  • Sega NAOMI GD-ROM MAME ROM support

Gambatte Progress Report

Libretro Team

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!

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

Libretro Team

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

Recommendations

Moving forward, we recommend that you remove the BeetleDC OIT Libretro core from your cores directory, and leave only the regular BeetleDC 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, BeetleDC 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).