New Vulkan graphics enhancements features in Beetle PSX HW!

MDEC YUV filtering

PlayStation used a special unit called the MDEC to decode full motion videos instead of relying on software rendering (like the Saturn). These videos were encoded in YUV macroblocks and had to be converted from YCbCr to RGB so that the PSX can output the final image to the screen. A common issue with PlayStation emulators is that the chroma channel generally should be smoothed, but the PlayStation tend to leave it unfiltered.

There’s now a feature called ‘MDEC YUV smoothing’ which does filter the chroma channel. You can see the before/after screenshot above (video in question is the Resident Evil 1 intro) to see the kind of visual enhancement this brings to the picture.

SSAA (Super Sampled Anti Aliasing)


Some people prefer to play PlayStation1 games at native resolution and just applying a CRT shader at the end instead of running them at very high resolutions. However, there are some issues with that approach. 3D polygon graphics can tend to look very aliased and jagged and lacking in definition.

Alternatively, others like to crank the resolution up as high as possible. Both approaches have their pros and cons, but a definite disadvantage is that early 3D was very primitive so you might not want to see razor sharp angular polygons rendered at obscene resolutions, especially when a game relies a lot on pre-rendered backgrounds and other 2D elements. The Final Fantasy and Resident Evil games come to mind for one.

The option ‘Adaptive smoothing’ already exists and it attempts to distinguish 2D elements from 3D elements. It will smooth out the 2D elements but leave the 3D elements alone, resulting in a high resolution picture with the 2D elements not looking pixelated and ugly.

This new Vulkan-only option, SSAA, is a completely new approach. The image is rendered at the internal resolution you set it at (2x/4x/8x/16x, you name it). It then downsamples it at the final output stage back to a resolution somewhere in the ballpark of 240p. What you get is a low-resolution image with very clean anti-aliased 3D, kinda similar to the N64 actually which had native 8x multi sampled anti aliasing of some sort.

Certain CRT shaders expect a 240p-ish image to look their absolute best, so this option lends itself very well to that. It also can tend to look bit more coherent with mixed 2D and 3D in cases where adaptive smoothing fails.

Tip: We recommend you turn dithering off when using SSAA (Super Sampled Anti-Aliasing).

Example – Final Fantasy IX

Below you see SSAA in action with Final Fantasy IX on RetroArch. The first image is SSAA at 1x internal resolution. The second image is SSAA at 8x internal resolution. You can see how the downscaling does its magic in the second picture – it results in an image that almost looks like as if the polygon characters are part of the background itself.

Finally, a CRT shader is used – crt-royale-ntsc-320px.

Final Fantasy IX – SSAA at 1x internal resolution with CRT Royale
Final Fantasy IX – SSAA at 8x internal resolution with CRT Royale

Dithering for Vulkan

PlayStation and N64 output the final image at 16 bits per pixel. Since that isn’t a particularly wide colorspace, both systems used dithering in order to fake the illusion of a larger palette of colors. This combats color banding and wouldn’t be very noticeable at native resolutions on a CRT TV. On more powerful hardware and when emulated, the limitations of this approach become clear, and some would prefer either internally rendering the dithering at the internal resolution, or disabling it altogether.

Dithering was previously ignored by the Vulkan renderer and was always turned off, no matter what you configured. Now it will actually let you enable it. If dithering is enabled, the scanout image will be 16 bits per pixel. If it is disabled, the scanout image will be 32bits. We recommend that you turn dithering off if you are going to be using ‘SSAA’ (Super Sampled Anti Aliasing)

Reicast Libretro NAOMI and MAME ROM support!

Flyinghead is adding MAME ROM support to the arcade side of Reicast 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 Reicast Libretro if you loaded .lst files. .lst files are no longer necessary now. You should be able to run an arcade game with Reicast 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/reicast-emulator/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

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!