Introducing BeetleDC OIT libretro core + updated BeetleDC regular core

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.6.7 -Released!

NOTE: This is a bugfixed and spit-and-polish update. The initial release notes below are still from the 1.6.6 release.

RetroArch 1.6.7 has just been released! Grab it here.

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

General changelog

– SCANNER: Fix directory scanning.
– SCANNER: Fix file scanning.
– COMMON: Fix ‘Disk Image Append’ option.
– FREEBSD: Compatibility fixes for Video4Linux2 camera driver.
– GUI: (MaterialUI) Add disk image append icons.
– GUI: (MaterialUI) Improve word wrapping when menu icons are enabled.
– GUI: (MaterialUI) Add User Interface -> Appearance -> Menu Icons Enable. You can turn on/off the icons on the lefthand side of the menu entries.
– GUI: Performance optimizations for XMB menu driver – only calculates visible items.
– LOCALIZATION: Update Italian translation.

Core updates since previous version (1.6.6)

  1. Picodrive should hopefully work now again on Android after notaz‘ updates.
  2. Beetle PSX’s OpenGL renderer should now work on various AMD GPUs thanks to rz5‘s efforts. There were previously some black screen issues on certain non-Polaris AMD GPUs.
  3. Beetle PSX – Fixed bugs (geometry updates had max width and height unset, other ones) (by albertofustinoni).
  4. Beetle Saturn – Unloading game leaves core unusable fix (by albertofustinoni).
  5. Beetle Supergrafx – add turbo on/off for 2-button controller mode (by retrowertz).
  6. Prosystem – NTSC Color Palette updates and DB updates (by underball).

RetroArch 1.6.6 has just been released! Grab it here.

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

General changelog

– 3DS: Fixes serious performance regression that affected every core; rewind was always implicitly enabled.
– AUDIO: MOD/S3M/XM sound should now be properly mixed in with the core’s sound.
– GUI: Visual makeover of MaterialUI.
– GUI: Added ‘Music’, ‘Images’ and ‘Video’ collection options to RGUI/MaterialUI.
– GUI: Allow the user to add ‘Favorites’.
– GUI: Allow the user to rename entries.
– GUI: Performance optimizations for XMB menu driver.
– LOCALIZATION: Update Italian translation
– INPUT: Overlay controller response – when we press buttons on the gamepad or keyboard, the corresponding buttons on the overlay will be highlighted as well.
– NETBSD: Silence some compilation warnings.
– COMMON: Fixed bug ‘Deleting an entry from a playlist would not update the list view inside XMB’.
– COMMON: Fix inet_ntop_compat on *nix

If you want to read about the latest bounty and core updates, read this post instead here.

Complete overhaul of the mobile User Interface! (MaterialUI)

On mobile devices, RetroArch uses the mobile UI, MaterialUI, by default. This interface is designed around touchscreen and pointer devices like a mouse/trackball.

We have given this menu interface a significant overhaul now for version 1.6.6! We are aware that there is a significant percentage of people that to date have been completely unsatisfied with the current state of the menu system on mobile devices like Android and iOS. Our menu UI improvements in version 1.6.6 is our first step to try to remedy this. In later releases, we might follow it up with more elaborate animations, more advanced widgets, etc.

The menu should look less monotonous now due to the usage of context-specific icons. We have also made some other UX improvements:

– The opacity of the game’s image clashed quite badly with the ingame menu before. This has been rectified.
– We have added ‘Music’, ‘Image’ and ‘Video’ playlists to the ‘Favorites’ tab.

Music, Video and Images which have previously been loaded in RetroArch can be easily accessed from the Playlists tab now.
Music, Video and Images which have previously been loaded in RetroArch can be easily accessed from the Playlists tab now.

– The file browser is easier to read now because files show up with specific icons to indicate what they are. For instance, music files have a music icon, a directory has a folder icon, selectable content files show up as a plain file, etc.

The file browser is easier to read now because files show up with specific icons to indicate what they are. For instance, music files have a music icon, a directory has a folder icon, selectable content files show up as a plain file, etc.
The file browser is easier to read now because files show up with specific icons to indicate what they are. For instance, music files have a music icon, a directory has a folder icon, selectable content files show up as a plain file, etc.

Usability tips

You can customize the color theme of the menu in MaterialUI at any time.

1 – Go to User Interface.
2 – Go to Views.
3 – Go to ‘Menu Color Theme’ and set it to the color theme you want.

General menu improvements

Favorites

You can now add a game to a ‘Favorites’ list for easy access! This has been an often-requested feature for years, and in the past we always felt that ‘Load Recent’ was good enough. However, if you load a lot of content, that can easily get cluttered over time.

To add a game to the Favorites list, do the following:
1 – Once a game is running, go to ‘Quick Menu’.
2 – Select ‘Add To Favorites’.
3 – Once added, you can now start the game at any time from the Favorites list.

On RGUI – go to Load Content -> Favorites.
On MaterialUI – go to the Playlists tab -> Favorites.
On XMB – go to the Favorites tab.

To add a game to the 'favorites' list, inside Quick Menu, select 'Add To Favorites'. It should now be added to the Favorites list. You can access the 'Favorites' list inside MaterialUI by going to the Playlists tab. On RGUI, you go to Load Content -> Favorites. On XMB, you go to the Favorites tab instead.
To add a game to the ‘favorites’ list, inside Quick Menu, select ‘Add To Favorites’. It should now be added to the Favorites list. You can access the ‘Favorites’ list inside MaterialUI by going to the Playlists tab. On RGUI, you go to Load Content -> Favorites. On XMB, you go to the Favorites tab instead.

Renaming entries inside playlists

You can now rename an entry from any playlist!

To do this, do the following:

1 – Go to a playlist of any type (it can be the history list, a system playlist, favorites, music/video/images playlists, etc).
2 – There should be an option called “Rename”. Select it. If you are using MaterialUI and/or XMB, an onscreen keyboard will now pop up. Input the new title for the entry and then hit either the Enter key on your keyboard ,the Start button on your gamepad or press the ‘Enter’ key on the onscreen overlay in order to confirm the changes.

You can now rename any entry! Say for instance you loaded a Quake data file. Instead of the playlist showing 'PAK0.PAK', you can rename it to Quake 1 instead.
You can now rename any entry! Say for instance you loaded a Quake data file. Instead of the playlist showing ‘PAK0.PAK’, you can rename it to Quake 1 instead.

Overlays show button presses

Previously, overlays would only show button presses if they were actually being clicked on by either the touchscreen or the mouse.

A user submitted a bounty to make onscreen reactions possible through the gamepad and/or keyboard. A bounty hunter has now successfully completed this bounty and has been paid out. We have enabled this feature by default. If you want to turn it off, you can do so by doing the following:

1 – Go to Onscreen Display -> Onscreen Overlay.
2 – Go to ‘Show Inputs on Overlay’. Set this to off if you don’t want the overlay to react to keyboard/gamepad input, turn it on if you want this to happen (turned on by default).

Nintendo 3DS regression fix – all cores were running slower

A serious issue has been fixed in the Nintendo 3DS RetroArch port which compelled us to push this release sooner rather than later.

It appears that by mistake, rewind was always forcibly enabled in the 3DS port, which led to a halving of performance. This should now be fixed.

What’s next?

The new cores

We are still determined to get the promised cores like PPSSPP into your hands before the end of the month. We just felt it very important to get this release out of the door so that people can see that we are determined to improve the menu on mobile, and also so that the 3DS RetroArch port is repaired again.

Wii input fix

Finally, after years of struggling with this very pesky issue, it seems we are on the verge of a breaktrhough here that could lead to this random input issue finally being fixed –

https://github.com/SuperrSonic/RA-SS/commit/29d6467d28a835136b8ab87e209feb34421983ff

it seems there was a regression in libogc at some point which lead to this input regression. Superssonic reports that going back to an older version of Wiiuse fixes the issue. What we are probably going to do is make a custom baked-in libogc version for the Wii port for the next release.

Shader Changes

Abstract

GLSL shaders now preferred over Cg when possible
Update to latest RetroArch for compatibility with updated GLSL shaders

Cg shaders demoted, GLSL promoted to first-class

Portability and compatibility are major goals for RetroArch and libretro, so we invested heavily in Nvidia’s Cg shader language, which worked natively anywhere their Cg Toolkit framework was available (that is, Windows, Linux and Mac OS X), as well as on PS3 and Vita, and could be machine-compiled to messy-but-usable GLSL (lacking a few features, such as runtime parameters) for platforms that lacked the framework (primarily ARM / mobile platforms). Cg was also so close to Microsoft’s HLSL shader language that many Cg shaders will compile successfully with HLSL compilers, such as those available with Windows’ D3D driver and on Xbox 360.

This was great for us because we could write shaders once and have them work pretty much everywhere.
Sadly, Nvidia deprecated the Cg language in 2012, which left us in a bad spot. Since then, we’ve been limping along with the same strategy as before, but with the uneasy understanding that Nvidia could stop supplying their Cg Toolkit framework at any time. Rather than sit idly by, waiting for that other shoe to drop, we took it upon ourselves to hand-convert the vast majority of our Cg shaders to native GLSL with all of the bells and whistles. TroggleMonkey’s monstrous masterpiece, CRT-Royale, still has a couple of bugs but is mostly working, along with its popular BVM-styled variant from user Kurozumi. Additionally, before this conversion, many of our Cg shaders were flaky or completely unusable on libretro-gl cores, such as Beetle-PSX-HW’s OpenGL renderer, but these native GLSL conversions should work reliably and consistently with any core/context except for those that require Vulkan (namely, ParaLLEl-N64’s and Beetle-PSX-HW’s Vulkan renderers).

With the GLSL shaders brought up to speed, we can finally join Nvidia in deprecating Cg, though it will still remain as an option–that is, we’re not *removing* support for Cg shaders or contexts at this point–and we will continue to use it where there is no other choice; namely, Windows’ D3D driver and the Xbox 360, PS3 and Vita ports. Moving forward, our focus for shaders will be on native GLSL and our slang/Vulkan formats, though we will likely still port some to Cg from time to time.

RetroArch now correctly handles #version directives in GLSL shaders; GLSL shader repo updated to match

There have been a number of updates to the GLSL shader language/spec over its long life, and shader authors can use #version directives (that is, a line at the top of the shader that says #version 130 or whatever) to tell compilers which flavor/version of GLSL is required for that shader. However, RetroArch has long had a strange behavior whereby it injected a couple of lines at the beginning of all GLSL shader files at compile time, and this broke any shader that attempted to use a #version directive, since those directives must be on the first line of the shader. This meant that our shaders couldn’t use #version directives at all, and all of our shaders lacked #version directives until very recently for this reason. These #version-less GLSL shaders are still perfectly compliant GLSL because GLSL v1.10 didn’t support directives, either, but the necessity of leaving off the #version started to cause some problems as we whipped our GLSL shader library into shape.

The error caused by adding a #version directive under the old behavior.

On AMD and Nvidia GPUs, the compilers would just toss up a warning about the missing directive and still expose whatever GLSL features were available to the GPU, which worked out great. On Intel IGPs, however, the compiler tosses the error and then reverts to only exposing the features available in ancient GLSL v1.10 (released way back in 2004). As a stopgap, we gave many shaders fallback codepaths that would still work in these circumstances, but a number of other shaders were either impossible to make compatible or even the compatible result was imperfect.

So, as of this commit (courtesy of aliaspider), RetroArch will no longer reject shaders with explicit #version directives, and we have added those directives to any shaders that require them at the lowest version that still compiles/functions properly. That is, if the shader doesn’t use any features that require greater than #version 110, they will still have no #version specified, and any shader that requires #version 120 but not #version 130 will not have its requirements increased to the higher version for no reason. This should keep our GLSL shaders as compatible as possible with older hardware, and including the #versions explicitly when needed will also make it easier for other programs/developers to utilize our shaders without any unnecessary guesswork due to behind-the-scenes magic.

This change does require a clean break, insofar as older versions of RetroArch will choke on the new #version directives (that is, they’ll fail to compile with the “#version must occur before any other program statement” error pictured above), so users with Nvidia or AMD GPUs must update their RetroArch installation if they want to use the updated shaders. Users with Intel IGPs will be no worse off if they don’t update, since those shaders were already broken for them, but they’ll probably *want* to update to gain access to the many fancy shaders that now work properly on their machines.

Mobile GPUs using GLES had many of the same issues that Intel IGPs had, with many shaders refusing to work without #version directives, but GLES compatibility added in a further complication: GLES requires its own separate #version directives, either #version 100 es or #version 300 es, which are different from and incompatible with desktop GL’s #versions. To get around this, we added a trick in RetroArch to change any #version of 120 or below to #version 100, which is roughly comparable in features to 120, and any #version 130 or above to #version 300 es whenever a GLES context is used. This should get everything working as effectively and consistently as possible on mobile GPUs, but if anything slipped through the cracks, be sure to file an issue report at the GLSL shader repo.