Introducing BeetleDC OIT libretro core + updated BeetleDC regular core

Libretro Team

The BeetleDC libretro core has seen several big improvements as of late, and we thought it would be remiss of us if we did not take this opportunity to talk about it.

There are two cores now

There are now two BeetleDC cores:

  • BeetleDC regular
  • BeetleDC OIT

BeetleDC regular: Contains an OpenGL renderer that requires OpenGL 2.x on the desktop and GLES 2.x on mobile.

BeetleDC OIT: Contains an OpenGL renderer that requires OpenGL 4.3, and as a result is only available for Windows and Linux. BeetleDC OIT might have significantly increased system requirements, but in return you get much more accurate graphics which tend to fix nearly all the issues that plague Dreamcast graphics with the regular version.

How to get it

In RetroArch, go to Online Updater -> Update Cores. From there, BeetleDC and BeetleDC OIT should be available for the following platforms:

  • Linux
  • Windows
  • Mac (Reicast OIT is not available for Mac due to no GL 4.3 support)

What is new/improved in both Reicast versions?

BeetleDC regular

BeetleDC regular’s OpenGL renderer has received many improvements that greatly increases the graphics accuracy and squashes many graphics bugs that plagued games in the past.

Here are some of the Dreamcast’s GPU features that are now implemented:

  • Tile clipping support.
  • Fogging support.
  • Volume modifier shadow support.
  • Multipass rendering.
  • Render to texture buffer.
  • Log 2 depth buffer.

Some additional enhancements include a log 2 depth buffer, fixing much of the polygon glitching that could happen in the distant background in many games.

All of these additions to the existing GL2 renderer in BeetleDC regular come courtesy of flyinghead.

BeetleDC OIT

BeetleDC OIT uses an entirely new graphics renderer written by flyinghead targeting OpenGL 4.3. In addition to boasting all the features that BeetleDC regular also enjoys as of this date, it also has the additional advantage of incorporating Order Independent Transparency, so that we don’t have to do hacky and error prone alpha sorting hacks, which is our main resort in BeetleDC regular.

  • Tile clipping support.
  • Fogging support.
  • Volume modifier shadow support.
  • Multipass rendering.
  • Render to texture buffer.
  • Log 2 depth buffer.
  • Order independent transparency.
  • Two-volume mode support.

NOTE: This requires a compatibility context for OpenGL 4.3. You might encounter issues with Intel/AMD GPUs right now on Linux using Mesa drivers since they require core context. Core context cannot currently be used because there are still graphic bugs to be solved when using this.

Showcase of new emulated features

Flyinghead has a terrific fork of Reicast that dramatically increased the rendering accuracy of BeetleDC’s OpenGL renderer. We backported these features with the gracious help of flyinghead. All kudos goes to him.

Tile clipping support


The Dreamcast’s PVR2 had a tile clipping GPU feature that was used to obscure portions of the screen. It was cheaper to keep rendering portions of the screen that were not meant to be seen by the user and just clip them away instead of deciding not to render them at all. This was previously unimplemented, which led to all sorts of graphics glitches. This has now been finally implemented in both cores.

Fogging support


The Dreamcast had a 128-bit fogging table that games could take advantage of. Plenty did, such as Cannon Spike, Blue Stinger, Resident Evil: Code Veronica, Virtua Fighter 3tb, and more games. This is now finally implemented for both cores.

Volume modifier shadow support


The Dreamcast made use of volume modifiers in order to simulate shadows in many games. This was previously either completely unimplemented or very buggily rendered. Volume modifiers are now correctly implemented in both cores (BeetleDC and BeetleDC OIT). Performance costs should be minimal and you definitely notice the shadows being cast now by characters and other objects.

Multipass rendering


The game V-Rally 2 relies on multipass rendering for rendering the UI elements on top of the game screen. This has finally been emulated on both cores (BeetleDC and BeetleDC OIT).

Render to texture buffer


Not only has render to texture being reimplemented (leading to much faster performance), but certain games such as Tony Hawk’s Pro Skater 1/2 would render to VRAM for rendering shadows. The upshot of this is that the shadow looks much more convincing vs. merely using volume modifiers in order to simulate shadows. This feature has been finally implemented in both cores.

Log 2 depth buffer


Thanks to the logarithmic depth buffer, many rendering bugs have been fixed. Some games have been completely fixed as a result, such as Cannon Spike, while others such as Soul Calibur no longer have the scenery in the background glitch out.

Note that this relies on gl_FragDepth being available. This might become an issue when we bring the BeetleDC libretro core to mobile, since it’s not a part of the GLES2 spec and might require either extensions or GLES3 support.

Order Independent Transparency

NOTE: This feature is exclusive to BeetleDC OIT, and is not available in the regular BeetleDC core.


Other improvements

Date/time saving is finally fixed


Finally you don’t have to keep inputting date/time again whenever starting a game with the BeetleDC cores.

Be sure to set a correct date/time, as entering a wrong date might lead to it not being able to save.

Analog triggers

The core finally supports analog triggers. The Dreamcast had analog L/R triggers, previously we only had digital trigger simulation, where the L1/R1 would simulate 50% press of the trigger and L2/R2 would be a 100% press of the trigger. While this mode is still available if you enable the option ‘Digital Triggers’, you can also now just take advantage of the new digital trigger capabilities.

In addition to this ,deadzone issues should be fixed now, so there should hopefully be no more analog input disparities between Xbox pads and PS4 pads.

Videos

RetroArch 1.7.3 – Released!

Libretro Team

RetroArch 1.7.3 has just been released! Grab it here.

This latest version has also been uploaded to the Google Play Store.

If you’d like to show your support, consider donating to us. Check here in order to learn more.

Highlights

New WIMP GUI for PCs!

RetroArch now has a WIMP GUI, powered by the powerful multimedia framework Qt! This feature is available currently for Windows and Linux. macOS users will have to wait a while longer for this feature to arrive to their platform.

The WIMP GUI works as a companion to the main RetroArch window. You bring it into view by pressing the F5 key on your keyboard. From there, you can do many tasks:

– Select a game from any playlist
– Browse the file system or any attached media storage device and load a game.
– Scan directories for content and generate system playlists.
– Associate cores to an entire playlist or associate only one entry of a playlist to a specific core

How to easily scan content

Totally customizable appearance

Switching between color themes

Multiple language support (English/Japanese)

Some things we’d like to note:
* This has been the combined work of bparker and Tatsuya79 that have worked tirelessly on this for a month. We are aware of several features that we’d like to implement, such as playlist editing, grid view layouts, etc.
* We are open to feedback on the GUI.
* You will likely not see this WIMP GUI on Android or iOS (or any game console for that fact) anytime soon. WIMP interfaces don’t lend themselves well to devices that rely on touchscreen or gamepad-based controls.
* (For Linux users) The Qt GUI should definitely work on X11. If you’d like to run it on Wayland, make sure you have the appropriate packages installed for Qt5 in your package manager. Be aware that Qt 5 cannot gracefully fail right now in case a platform module/plugin is missing from your system. This means that if you invoke the companion UI by pressing F5 on Wayland, and for whatever reason the platform module that Qt relies on in order to work on Wayland is not there, there is no way for RetroArch to gracefully fail there and just not show the companion UI. There will be a crash instead. Unfortunately we have talked to some Qt developers and they see no other way around this for now. The same situation applies for DRM/KMS right now. If we can find a better solution to this, we will certainly return to it.
* (For mac Users) You will have to wait a bit longer for this to arrive to the Mac port unfortunately. Hopefully that wait is not too long.
* We would like to still improve initial bootup times for the companion UI. Right now, on first initial startup, it can take anywhere from 5 to 10 seconds (depending on your harddrive and its performance), but on subsequent boots should only take 2 seconds or less for first startup. Hopefully by resorting to Link Time Code Generation and other avenues we can shave off some more seconds off this boot time.

Starting up the UI on startup


If you would like to start up the companion UI at first startup instead of having to manually press F5 first, you can do so. Make sure that Advanced Settings are enabled first (Settings -> User Interface -> Show Advanced Settings). After that, make sure the option ‘Show desktop menu on startup’ is enabled.

Real-time audio mixer controls – menu music, mixing of audio channels, separate volume controls, etc

In RetroArch 1.7.3 we have given RetroArch’s built-in audio mixer a huge overhaul.

Improved file format support – Now supports MP3 and FLAC thanks to mudlord. The audio mixer now supports MP3, FLAC, Ogg Vorbis, and WAV files in total.

Live manipulation/control of the audio mixer in the menu – you can now access the audio mixer inside the menu. You can set audio tracks to each of the 16 available streams, and you can issue commands to them such as Play (normal/Looping/Sequential), Stop or Remove.

Individual volume setting per audio stream – You can now also individually set the volume for each separate audio stream inside the mixer. If you wish to override all audio stream’s volume with one global override, you can go to Audio Settings and set Audio Mixer Volume Level. Reset this back to 0 dB if you want individual volume per stream to work again.

Increased the amount of max streams – Previously, the audio mixer was limited to 8 streams in total. This figure has been doubled to 16.

New album mode-like features – If you have a couple of tracks queued up in the audio mixer and if you’d like to play them back like a regular audio music player (played sequentially, one song after the other) – select ‘Play (Sequential)’. When the song is finished playing, it will look at the other streams directly down below it. If one of these streams is in ‘stopped’ state and if there is audio loaded there, it will start playing it. It will also in turn set this audio stream’s play state to ‘Sequential’ and it will keep going down the list until the end of the audio stream mixer’s ‘list’ has been reached.

Music can play inside the menu now – Previously, you could only listen to audio streams with the audio mixer once you were inside a game and a core had been loaded. Once you went back to the menu, the sound mixing would stop there. You can now set ‘Enable menu audio’ to ON in order to be able to have music inside the menu as well! You can seamlessly jump back and forth between menu and game and have the music continue running.

Other additional niceties –
* The music is mixed in with the rest of the core’s sound data, so the music also is affected by fastforwarding and is thus sped up when you fastforward it, just like regular game audio would.

NOTE: Not all platforms have received MP3 and FLAC support yet. So far, we have enabled it already for Windows, macOS, Linux, Android and iOS. More platforms might follow.

Runahead – improved performance with Genesis Plus GX

Dwedit sent some patches to improve Genesis Plus GX’s performance with runahead. We put this briefly to the test on the Xbox OG. Previously with 1.7.2, Sonic 2 on version 1.7.2 did not reach fullspeed with runahead set to 1 frame. With version 1.7.3, we can finally play at fullspeed with runahead set to 1 frame. Setting it any higher than 1 proves too taxing for the old system.

Game Core Description FPS – 1.7.2 FPS – 1.7.3 Format
Sonic 2 Genesis Plus GX No runahead Fullspeed Fullspeed Xbox OG
Sonic 2 Genesis Plus GX Runahead – 1 frame Not fullspeed Fullspeed Xbox OG

CRT Switch Res on Linux – GroovyMAME-like features for 15KHz capable CRT monitors!

Starting as of version 1.7.2, RetroArch now has the ability to query cores for their exact video timing data, which can be used to switch to native-resolution, 15 kHz modelines for use with standard-definition CRT TVs.

This is a big step for retro purists, as RetroArch can now output “pixel-perfect” video with accurate timing to compatible displays, even quickly switching between interlaced and non-interlaced modes on the fly.

This capability was previously Windows-only and requires modelines to be created in advance by CRT_EmuDriver or Custom Resolution Utility with a compatible GPU.

Starting as of version 1.7.3, Linux support has been implemented too!

In case you’d like to learn more, follow these links:

Input remapping system fixes for overlays

Radius fixed several bugs which would prevent the new input remapping system from working with onscreen overlays.

General changelog

AUDIO: Audio mixer supports FLAC/MP3 file types now!
COMMON: Fixed bug ‘crashing in cores that don’t range check retro_set_controller_type’. Some people were having crashes when device is set to RETRO_DEVICE_NONE and the cores don’t check the number of ports, in VBAM’s case it was overflowing and crashing. QuickNES was crashing too.
COMMON: Fixed buffer overflow in url encoding (affecting MSVC2010/2013).
COMMON: (QuickMenu) Added Configuration Override submenu.
HID: Merge new HID subsystem.
HID: Fix WaveBird support for the Wii U GCA.
HID/OSX: Fix regression with IODHIDManager – gamepads which are connected later would not be autoconfigured.
LOCALIZATION: Update Italian translation.
LOCALIZATION: Update Japanese translation.
LOCALIZATION: Update Portuguese translation.
MENU: New WIMP Qt GUI!
MENU: Audio mixer now works in the menu without any cores loaded. You have to enable the setting ‘Enable menu audio’ for this to work.
REMAPPING/OVERLAYS: Fix regression – overlays could no longer be remapped.
SCANNER: Add Wii Backup File WBFS support.
X11: CRT SwitchRes support for X11/Linux.

What is coming next?

We can already give you a sneak peek of some of the new features the new WIMP GUI will be having in the upcoming version. Right now, playlist entries are only displayed as a list. The new version will also allow you to display playlists in a grid view (both small and big). See the images below for an indication of how that will look like.

RetroArch 1.7.2 – Released!

Libretro Team

RetroArch 1.7.2 has just been released! Grab it here.

This latest version has also been uploaded to the Google Play Store.

If you’d like to show your support, consider donating to us. Check here in order to learn more.

Highlights

Runahead latency reduction – better latency than the real hardware

A visual representation by Durante of how the runahead system works in practice.
A visual representation by Durante of how the runahead system works in practice.

This might just be our biggest release yet, thanks in no small part to the new runahead latency reduction system. This feature has already been all the rage over the Internet. Well known people like Durante of DSfix fame praised it and the popular site Ars Technica has dedicated an entire article to this game-changing feature.

We ran an article on this new feature before, and since then, several facts have changed on the ground which bears pointing out. First of all, several performance improvements have been made since. Secondly, the feature has now been enabled for the vast majority of the RetroArch platform ports.

The versions that have this feature enabled and exposed now includes:

  • Wii
  • WiiU
  • Nintendo Switch
  • Android
  • PC (Windows)
  • PC (Linux)
  • macOS
  • iOS

Here are some basic things you should know:

  • Every game has a certain built-in amount of lag frames. In order for the runahead system to perform as expected, you should set it to the same amount of frames to read ahead that the game you’re running is working by. So, for example, if a game like Super Mario World for the SNES has a guaranteed 2 frame input lag, for the best results, set Runahead frames to 2.
    You can count the amount of lag frames a game has by using the frame advance feature in RetroArch.
  • For playable performance, your system should be at least capable of running the core at twice its regular speed. These performance demands go up commensurate to the amount of frames you want to run ahead. The higher performance you get with a core, the more frames you can run ahead at fullspeed.
  • While the runahead system is core agnostic and therefore technically we don’t need to patch up cores in order to work with the runahead system, there are several things that can be done in order to improve performance considerably. To this end, Dwedit has submitted several patches to some of the cores in order to make them perform much better. Some of these cores include (but are not limited to) the Snes9x cores, QuickNES, FCEUmm, Nestopia, Gambatte, and even Mednafen/Beetle PSX.
  • There are currently some things you should know about Mednafen/Beetle PSX when it comes to runahead. First of all, in order for this core to work correctly with runahead, you should use the software renderer. The OpenGL and Vulkan renderers are currently buggy with runahead. Second, even after several savestate performance improvements, it is unlikely you will be able to set runahead to higher than 1 frame while still being able to run at fullspeed. This might likely change once our bounty for the Beetle PSX dynarec is finally fulfilled (and on that note, it has already reached $720, and a coder is working on a potential solution)
  • An often heard question that has been asked is – will this work on a Raspberry Pi? There is no straight answer to this since it heavily depends on the core’s performance. Based on our performance tests on the PS3 and Xbox OG, QuickNES and Gambatte should be at least two cores that should run at fullspeed with runahead set to 6 frames or less. Your mileage may vary on any of the other cores. The quick rule of thumb is that the faster the core, the higher chance there is to get it to run at fullspeed with more runahead frames.

How to check the amount of lag frames a game has

RetroArch has the ability to pause a core and advance it frame by frame. Perform the following steps to determine the amount of lag frames of a game:

  • Pause emulation (press ‘p’ button on keyboard).
  • Press and hold the jump button on the controller.
  • Advance emulation frame by frame (press ‘k’ button on keyboard) until the character jumps.

The number of k presses before you get a reaction should be the number of lag frames you can safely remove with run ahead.

Performance, scalability

So, how well does all this scale? Of course, the more expensive hardware you throw at a latency reduction approach like this the better, but how low can we actually go in terms of specs and still obtain good results? To figure out a basic answer to this question, I decided to test the runahead system on two old game consoles that are not exactly powerhouses at this point. The first of the lot is the Xbox OG, powered by a fairly mundane Pentium 3/Celeron 733MHz CPU. The second is the PlayStation3. Its PPU is roughly equivalent to a Pentium 4 2.4GHz CPU in terms of real-world performance, and even that comparison is probably pushing it. So this is not exactly powerful hardware.

Street Fighter Alpha 3 FBAlpha 2012 No runahead 104fps PS3
Street Fighter Alpha 3 FBAlpha 2012 Runahead – 1 frame 57fps PS3
Mega Man 2 QuickNES No runahead 124fps PS3
Mega Man 2 QuickNES runahead – 1 to 6 frames 124fps PS3
Mega Man 2 Nestopia No runahead 124fps PS3
Mega Man 2 Nestopia Runahead – 1 frame 76fps PS3
Mega Man 2 Nestopia Runahead – 2 frames 54fps PS3
Super Mario World Snes9x 2010 No runahead 113fps PS3
Super Mario World Snes9x 2010 Runahead – 1 frame 78fps PS3
Super Mario World Snes9x 2010 Runahead – 2 frames 65fps PS3
Super Mario World Snes9x 2010 Runahead – 3 frames 56fps PS3
Sonic 1 Genesis Plus GX No runahead 116fps PS3
Sonic 1 Genesis Plus GX Runahead – 1 frame 51fps PS3
Bomberman 94 Mednafen PCE Fast No runahead 124fps PS3
Bomberman 94 Mednafen PCE Fast Runahead – 1 frame 83fps PS3
Bomberman 94 Mednafen PCE Fast Runahead – 2 frames 66fps PS3
Sonic 1 SMS Gearsystem No runahead 120fps PS3
Sonic 1 SMS Gearsystem Runahead – 1 frame 63fps PS3
Sonic 1 SMS Genesis Plus GX Runahead – 1 to 6 frames 124fps PS3
Mega Man 2 QuickNES Runahead – 1 to 6 frames Fullspeed Xbox OG
Mega Man 2 FCEUMM Runahead – 1 frame Fullspeed Xbox OG
Mega Man 2 FCEUMM Runahead – 2 frames Not fullspeed Xbox OG
Sonic 2 Genesis Plus GX No runahead Fullspeed Xbox OG
Sonic 2 Genesis Plus GX Runahead – 1 frame Not fullspeed Xbox OG

We consider any PC from the year 2005/2006 (whether desktop or laptop) to be significantly more powerful than either of those consoles, so these test results bode quite well for the scalability and feasibility of the runahead method.

Features like the runahead system will also naturally increase the demand for ever faster cores so that people on lower specced hardware can use runahead with more frames in advance.

CRT Switch Res – GroovyMAME-like features for 15KHz capable CRT monitors!

Thanks to forum-user Alphanu, RetroArch now has the ability to query cores for their exact video timing data, which can be used to switch to native-resolution, 15 kHz modelines for use with standard-definition CRT TVs.

This is a big step for retro purists, as RetroArch can now output “pixel-perfect” video with accurate timing to compatible displays, even quickly switching between interlaced and non-interlaced modes on the fly.

This capability is currently Windows-only and requires modelines to be created in advance by CRT_EmuDriver or Custom Resolution Utility with a compatible GPU. Linux support is coming soon.

In case you’d like to learn more, follow these links:

Direct3D improvements, additions, and a new Direct3D10 driver

With RetroArch 1.7.1, we really stepped our game up to finally start treating Windows as a first-class citizen platform. You have seen this in the form of dedicated Direct 3D 11/12 video drivers that had the ability to run the same shaders as Vulkan, our new slang shader spec that is made possible by the impressive Khronos/ARM-backed project SPIRV-Cross.

Increased backwards compatibility

Previously, the Direct3D 11 driver required that your graphics card driver supported at least Shader Model 5.0. We have since downgraded this requirement to Shader Model 4.0. As a result, I am now able to use the Direct3D 11 video driver on an old 2010 laptop GPU that only supports Shader Model 4.0 (it’s an ATI Mobility Radeon HD 4300). We also try to support more D3D11 feature levels instead of just defaulting to 11.0.

New Direct3D 10 video driver

On some systems, though, you won’t be able to make use of the Direct3D 11 driver no matter what. One of those systems happened to be another old laptop I had lying around here. This one has a Geforce 9200M GS, and the specs state that it supports up to Direct X 10 and Shader Model 4.0. Direct3D 11 is a no go on this GPU even with the increased backwards compatibility.

It’s for this purpose that me and aliaspider spent some time to finally make the Direct3D 10 driver feature-complete. Direct3D 10 should be available from Windows Vista and up, whereas Direct3D 11 is available from Windows 7 and up. The Direct 3D 10 driver should be feature complete and identical to the Direct3D 11 driver, with the sole exception of hardware rendering contexts not being available right now with Direct3D 10.

Which brings us to the last Direct3D-related subject…

Direct3D-powered libretro cores are now possible!

This feature is easily worth its own article, but since we already covered this before and because 1.7.2 has so many huge features, we will relegate this to a side note. Nevertheless, it is none the less important.

Up until now, if you wanted to use hardware-accelerated 3D rendering in a libretro core, your options were OpenGL and/or Vulkan. There is now a third option – Direct3D 11, and the first libretro core that supports this is the PPSSPP core!

With all these features, we now have everything in place to really do an UWP version of RetroArch justice.

Input remapping system improvements

The input remapping system (available from Quick Menu -> Controls) had many obvious limitations previously. Some of these included:

  • It was not possible to map keyboard from more than one gamepad (for instance with Dosbox)
  • It was not possible to map more than one button to the same action
  • It was not possible to unmap buttons or analogs
  • It was not possible to map a button to trigger an analog response (for instance, in an N64 emulator, running in Super Mario 64 with the D-pad)
  • It was not possible to map an analog to another analog
  • It was not possible to map an analog to produce a button response

Most of these restrictions have now been lifted at long last thanks to radius, and the visual representation is also much improved now.

To read more about this, also visit the related forum thread here.

Do note that all your existing remap files are now obsolete, and you should start from scratch. This was a necessary evil unfortunately in order to progress.

Various Quality-Of-Life improvements

We have tried to do various consequential Quality-of-Life improvements for this release:

  • XMB and MaterialUI menus should scale much better now depending on the output resolution. Previously, the XMB and MaterialUI menu elements were too small if you were running at a resolution of 1440p or 4K.
  • Boxart / thumbnails now react better to other elements on the screen and can resize or adjust themselves accordingly. There are also new ways of showing a thumbnail on the left and right side of the screen in XMB. It is also possible to determine what ‘type’ of thumbnails get shown on the left and right, respectively.
  • There are two layout modes now for XMB – you can choose between Desktop and Handheld. Desktop is the default look of the XMB as it was now, mirroring the PS3 layout, while Handheld goes for an XMB look that is more in line with how it looked like on PSP. Previously, the default layout was ‘automatic’, where it would default to the PSP layout if you were running at a resolution of 320×240.
  • Shaders should work again with the Vulkan video driver on the Android version.
  • When you select a shader preset now, it should only show you the supported shader presets based on the video driver that is currently selected. In other words, it will no longer show you GLSL shaders and/or presets when you have selected the Vulkan video driver, just as an example.
  • Certain video features were never implemented for some platforms. We now hide features like Black Frame Insertion, GPU Hard Sync and Swapchain images if the video driver in question doesn’t implement them. It is conceivable that for some of these drivers, these features might be implemented later, but overall we feel it declutters the menu considerably by simply not showing settings that have no effect at all when toggled due to them being unimplemented.
  • We now expose certain convenience features on the Quick Menu, such as Latency, Rewind and Overlay settings. You can also hide these settings respectively by going to User Interface -> Views -> Quick Menu and disabling these categories.
  • The shader next/previous hotkeys are more intelligent now and deliberately skip over shaders that are not supported by the current video driver.
  • (For Linux users) Wayland should now have proper scaling with XMB menu driver.
  • (For Linux users) Allow compositor disabling on X11 fullscreen through _NET_WM_BYPASS_COMPOSITOR.
  • On platforms where this is supported, ‘Set Display-Reported Refresh Rate’ is a convenient way of setting the exact refresh rate that the OS/video driver has reported to the application. This might be more accurate than measuring the refresh rate yourself by waiting for 2048 samples or more before hitting the Action button on ‘Estimated Screen Framerate’.
  • Display Framerate is now moved to ‘Onscreen Display – Notifications’. A handy feature showing all sorts of statistics is now exposed in this submenu as well.

  • RetroAchievements updates

    The future is now. Arcade achievements using the FB Alpha core are fully supported in this version. This brings support for Neo Geo and Capcom arcade boards (Metal Slug, Marvel Super Heroes).

    – Capture your greatest moments with the automatic screenshot feature! Look back fondly on the time you grinded your RPG character to level 99 for internet points.

    – RetroAchievements on a retro computer?! Windows XP builds of RetroArch now support achievements!

    General changelog

    ANDROID/OPENSL: Prevent crashes when setting audio latency too low (buffer count can never be lower than 2 now).
    CRT: Added CRT SwitchRes.
    COMMON: Hide the ‘Core delete’ option if the ‘Core updater’ is also hidden.
    COMMON: Add way to reset core association for playlist entry.
    COMMON: Fix invalid long command line options causing infinite loop on Windows
    COMMON: Add OSD statistics for video/audio/core.
    COMMON: Added runahead system; allows you to drive down latency even further.
    COMMON: Fix buggy behavior that could happen with ZIP file reading on some platforms as a result of not initializing struct.
    CHEEVOS: Support Atari 2600, Virtual Boy, and Arcade (only Neo Geo, CPS-1, CPS-2 and CPS-3 and only with fbalpha core).
    CHEEVOS: Add option to automatically take a screenshot when an achievement is triggered.
    CHEEVOS: Fixed incompatibilities with Neo Geo Pocket achievement sets.
    CHEEVOS: Store only login token, not password.
    D3D10: Added D3D10 driver to release build. Has working shaders (Slang), overlay, and menu display driver support. Should be on par capabilities wise with D3D11 driver except for there being no hardware rendering right now.
    D3D11: Experimental hardware renderer. Allows for libretro cores to use D3D11 for hardware rendering. First core to use this is PPSSPP.
    D3D11: Increase backwards compatibility, shaders compile with Shader Model 4.0 now, added support for more feature levels.
    D3D10/D3D11/D3D12: Fix crashes with completely black or white thumbnail textures in XMB.
    GUI: Support disabling window decorations on Windows and Linux.
    LIBRETRO: Addition – Functions to enable and disable audio and video, and an environment function to query status of audio and video enables.
    LOCALIZATION: Update Italian translation.
    LOCALIZATION: Update Polish translation.
    MENU: Add Rewind/Latency/Overlay settings to Quick Menu, add options to show/hide them (User Interface -> Views -> Quick Menu)
    MENU/RGUI: Only show Menu Linear Filter for RGUI and only show it for video drivers that implement it (D3D8/9/10/11/12/GL)
    MENU/RGUI: Add User Interface -> Appearance options.
    MENU/RGUI: D3D8/D3D9: Hookup Menu Linear Filter
    MENU/XMB: Disable XMB shadow icons by default for PowerPC and ARM for performance reasons.
    MENU/XMB: Left/right thumbnails are now automatically scaled according to layout.
    MENU/XMB: Add Left Thumbnails (additional to the right).
    MENU/XMB: Fixed left/right tab regression.
    MENU/XMB: Fix scaling of tall images that were cut on bottom previously.
    MENU/XMB: Menu scale factor setting now changes texts length, image scaling and margins.
    MENU/XMB: Mouse cursor scales correctly now.
    MENU/XMB: Add toggle to show/hide Playlist tabs.
    MENU/XMB: Add menu layout – can switch between Desktop, Handheld and Auto.
    MENU/XMB: Don’t load menu pipeline shaders unless XMB is selected (D3D10/D3D11/D3D12/GL/Vulkan)
    MENU/VIDEO: Only show black frame insertion for the video drivers/context drivers that support it (so far this includes – D3D8/D3D9, OpenGL, Vulkan)
    MENU/VIDEO: Only show max swapchain images if supported by video driver and/or context driver (so far this includes – DRM EGL context driver, VideoCore EGL context driver, Vulkan)
    MENU/MaterialUI: Automatic DPI Scaling should be much improved now, now scales as expected at 1440p and 4K resolutions.
    MENU/MaterialUI: Fix wrong calculation of an entry height causing long playlists to end up outside of screen range. This also could cause crashes on low DPI screens.
    IOS: Fixed crash when opening downloaded roms from Safari or using the “Open in..” functionality. Added the compiler flag to support keyboard remapping to controls.
    IOS: Fixed buffer overlap that caused a crash while trying to download GLSL shaders from the buildbot.
    REMAPS: Mapping keyboard keys from more than one gamepad (works with dosbox)
    REMAPS: Mapping more than one button to the same action
    REMAPS: Unmapping buttons
    REMAPS: Unmapping analogs
    REMAPS: Mapping a button to trigger an analog response (tested with mupen, can run on SM64 with the d-pad now, triggers a full analog tilt)
    REMAPS: Mapping an analog to another analog (having more than one analog mapped to the same output causes issues)
    REMAPS: Mapping an analog to produce a button response
    SCANNER: Should be able to scan dual-layer Wii disc images now, filestream code now supports files larger than 4GB.
    SHADERS/SLANG: Slang shaders should work again on Android version and MSVC versions (basically all the Griffin-based versions).
    SHADERS: If GL context is GLES2/3/Core context, Cg shaders are unavailable. Applies to shader list too.
    SHADERS: Hide cg/glsl shaders from being able to be selected if D3D8/9/10/11/Vulkan video drivers are selected.
    SHADERS: Hide slang shaders from being able to be selected if D3D8/9/OpenGL video drivers are selected.
    SHADERS: Prevent crashes from occurring if we have the GL video driver in use and we try to skip to a slang shader through next/previous hotkeys
    SHADERS: Fix shader parameter increase / decrease functions
    SUBSYSTEM: handle savestates properly (cart1 + cart2.state0)
    VULKAN/X11: Fix X11 Vulkan bug from Wayland driver.
    VULKAN: Fix multi-line text spacing in menus with Vulkan driver.
    WINDOWS XP: Add Cheevos support.
    WINDOWS/MSVC 2003/2005/2010/2013/2015/2017: Add Cheevos support.
    VITA: Bugfix for ‘PS Vita takes many time to start to accept input’ issue.
    X11: Allow compositor disabling on X11 fullscreen through _NET_WM_BYPASS_COMPOSITOR
    X11: Prioritize NET_WM_STATE_FULLSCREEN in true fullscreen mode
    WIIU: Fix OOB read/write in keyboard driver.

    What’s coming next for RetroArch

    So, RetroArch 1.7.2 had some pretty major new features, right? By all indications, it looks like RetroArch 1.7.3 will be no different. So let us give you some sneak peek at what might be arriving down the road for the next version…

    A Qt-powered WIMP desktop UI!

    Ever since RetroArch’s inception in 2012 (and even way before that when it was just known as SSNES), we have stuck to our guns and insisted on a uniform menu experience that obviously took its design cues from mainstream gaming consoles like the PlayStation.

    While this lends itself very well to game consoles and the like, there is also a very vocal minority (or majority, depending on how you look at it) that has definitely made it well known that they would really prefer a native WIMP UI at times to be able to do mundane tasks like select/load a ROM, or browse through a playlist easily with the mouse, etc. And certainly, an argument can be made that on a traditional desktop PC, it might not be ideal at all times to be confined to the same kind of input limitations as say a traditional gamepad.

    For 1.7.3, the way we will try to reach for a concession with these users will be through the way of this companion UI. What you see in these screenshots will be a WIMP (Windows, Icons, Menus, Pointers) GUI powered by Qt. It will be available for RetroArch versions that run on PC Operating Systems like Linux, Windows and macOS.

    The way we envision this UI to work is a bit like how it is possible in Steam to switch between Big Picture mode and the traditional desktop UI. We still want the console-style menus to be RetroArch’s main user interface and we believe this scales fairly well onto game consoles, mobile devices and handhelds. But there is no denying, as Windows 8 all taught us, that there is no such thing as one true universal UI that can scale well across every potential device, so the user should definitely have his/her options.

    The two screenshots you see here are not just mockups, they are already operational in bparker’s branch. What you see here is the result of about one solid month of work, and it’s already reaching quite satisfactory levels.

    We have kept a tight lid on it until now, but felt the time was right to reveal more details about it. We are doing this primarily for the users, and we hope that they will like it, and through designing this we are also trying to be more receptive to user feedback than we might have been in the past.

    Despite all this, as with anything in our codebase, we do insist that from a programming point of view, that this will not impose any huge dependencies, and that all of these individual coding parts are modular in nature and can be easily compiled in or out of any build. With RetroArch we always have to walk a fine line between staying lightweight and not becoming perceived of being too bloated yet also trying to meet increasing user expectations, and it’s not necessarily always possible to be in the middle of these two opposing camps. So we try to do our best to satisfy both groups this way, and stay true to our design goals while also making sure that we keep the users happy who don’t care about the underlying codebase but just care about the results from an enduser perspective of what they can do with the program. It’s a big challenge and definitely a balancing act but we feel we have become better over the years in terms of finding the right balance.

    2018 The Year Of The Libretro Frontend

    Libretro, the underlying platform and ecosystem that powers most of what you see in RetroArch, will see an explosive growth throughout the rest of this year, both by our efforts and outside forces also only tangentially related to our project. You will see the Libretro logo not only in more places, but you will also see popular programs like Kodi finally adopting the API wholesale.

    While it was never our direct intent to have our API be synonomous with retro gaming and emulators, we do not mind this being the biggest driver of growth in this emerging ecosystem and are grateful for the developments there.

RetroArch 1.7.2 — Achieving better latency than original hardware through new runahead method

Libretro Team

Even though sub-frame latency in software emulators has been achieved, some developers kept pushing beyond, and found a way to surpass even real hardware in response time. We have Dwedit to thank for this particular method.

Most systems more complex than the Atari 2600 will display a reaction to input after one or two frames have already been shown. For example, Super Mario Bros on the NES always has one frame of input latency on real hardware. Super Mario World on SNES has two frames of latency.

The Libretro forum post linked above provided patches to RetroArch that can effectively “remove” this baked-in latency by running multiple instances of a core simultaneously, and quickly emulating multiple frames at a time if input changes.

This strategy has some analogs to frame rollback, similar to how GGPO handles high-lag connections. And in fact, if you set the “read ahead” frames on the experimental builds ridiculously high, you can get a feeling for what’s going on behind the scenes.

Here’s another article from a few years ago illustrating the basic concept.

Accurate? No way. Fascinating? You betcha. Mere “same latency as real hardware” is SO last month…

This feature has since been incorporated into RetroArch and will make its first proper debut in the upcoming RetroArch 1.7.2. Users who want to get a sneak peek at this feature can already experiment with it by downloading the latest nightly version of RetroArch, and downloading the latest version of the Snes9x core.

Once the game is running, go to Settings -> Latency and/or Quick Menu – Latency.

The setting ‘Run-Ahead to Reduce Latency’ is what you want to enable. From there on out, you can specify the amount of frames that you want to run ahead. Be advised that how well this will work with the game in question will depend on the game’s built-in amount of lag frames, so experimentation is key here.

Be aware that this method is highly resource intensive. The higher the number of frames you are going to run ahead of emulation, the higher demands it places on your CPU.

This feature is enabled for the Windows, Linux, macOS, Android, iOS, PlayStation3, Xbox OG, Wii and WiiU versions.

We hope you will look forward to this feature and tons of other exciting changes that will be packed into RetroArch 1.7.2! Playing Super Mario World and other SNES games with their built-in 2/3 frames of latency removed is definitely a game changer and will hopefully breath fresh air into these old games.

If you would like a technical breakdown of this method, read this post here by Dwedit, the author of this method (incidentally, he also made PocketNES a long time ago, a NES emulator for the Game Boy Advance which was a big breakthrough back in its day).

Libretro API now supports experimental Direct3D11 hardware rendering!

Libretro Team

We, as the developers of RetroArch and Libretro, are proud to announce that yet another new option is available to developers who are using the Libretro API. In addition to being able to use Vulkan and/or OpenGL for hardware rendering, you can now also use Direct3D 11 inside your cores!

While it should be noted that this is still in an experimental stage, there is already a core that will be taking advantage of this — the PPSSPP libretro core, which has recently been upstreamed thanks to Ali Bouhlel and Henrik Rydgard, the original developer. You will be able to use either Direct3D 11 (on Windows), OpenGL or Vulkan renderers with the PPSSPP core.

Some history –

Libretro as an API started out in 2010/2011 only allowing for software rendered graphics. This is truly platform and hardware-agnostic, and for most systems that do not use any kind of 3D rendering and have little to gain from moving over to hardware-accelerated graphics APIs this is the preferable strategy. However, because software rendering has to be handled by the CPU, is only really practical for older games/emulators emulating older 2D-based systems.

OpenGL hardware rendering was added as an option to the Libretro API back in 2013. This coincided with Android and iOS ports appearing for RetroArch, and this was before the platform holders all decided to go their own separate ways and start targeting their own APIs. So being able to target OpenGL (ES and non-ES) as a developer in your libretro core was a great and convenient way to make cross-platform code that would run on most platforms. The only requirements for using OpenGL in your core was that you would adhere to at least OpenGL 2.x on the desktop and/or OpenGL ES 2.0 on mobile. While fixed-function OpenGL was theoretically possible, we only ever provided a test core for it, and we had an unwritten agreement in general that OpenGL usage in Libretro cores should be non-fixed function.

In 2016, the next-generation Vulkan graphics API was launched, and nearly at the same day, RetroArch and Libretro as an API started supporting the Vulkan API. Later that year, new Vulkan renderers for two of our emulators, Beetle PSX and Parallel N64, were made. Since then, Vulkan support has been added to other libretro cores as well, such as PPSSPP and the Dolphin core.

Now in 2018, there is an additional third option available to developers — Direct3D11 support! Targeting this API will of course limit you to Windows 7 and later. However, there are valid reasons for targeting Direct3D 11. On some devices like the Surface Pros, OpenGL drivers are apparently notoriously bad and you need to use Direct3D rendering in order to get decent performance. To this day, users of AMD GPUs on Windows still complain about OpenGL renderers performing worse than their Direct3D equivalents. Whether this is deliberate through sabotage or it’s just circumstantial misfortune, there are legitimate reasons for targeting Direct3D 11 from a performance perspective, and since UWP supports D3D11 natively and using either Vulkan or OpenGL would only be possible through several abstraction layers, it is nice in our humble opinion that the option exists vs. it not existing at all.

We would of course much prefer that there was a real crossplatform graphics API that magically worked everywhere, had great performance everywhere, and that required somebody to just write a graphics renderer once. Unfortunately, industry powers for whatever reason never seem to want things to actually get too easy for developers, so until then, covering all our bases with the Libretro API and trying to support as many of the predominantly available graphics APIs as possible seems to be a more pragmatic decision.

And what’s more, thanks to the excellent SPIRV-Cross project, we are fast approaching a situation where the Direct 3D 11, Direct 3D 12, Vulkan and (maybe soon?) OpenGL drivers available in RetroArch will be capable of using the same shaders instead of each needing their own separate shaders.

See here a video of PPSSPP running with Direct3D11 on RetroArch –