ANGLE is middleware developed by Google that serves as an OpenGL compatibility layer on systems where OpenGL support is either spotty or missing entirely. It converts OpenGL calls to Direct3D 9/11.
In this video, you will see ANGLE being used on RetroArch UWP. In specific, it allows us to run OpenGL cores now on the Xbox One, where only Direct3D 11/12 are available as graphics APIs. Mupen64plus Next is shown running in this video on an Xbox One S with fairly acceptable results.
Will this be ready for the next version?
We don’t know yet if this will make it for version 1.8.2.
Let us tell you though what this will entail in the future –
There will likely be two binaries from now on for the desktop Win32 Windows version – one with ANGLE, one without. The non-ANGLE version will use your system-provided OpenGL driver, while the ANGLE version will use the ANGLE version of the OpenGL dynamic libraries.
ANGLE works over OpenGL ES. This means that ANGLE requires separately compiled cores targeting OpenGL ES 2/3 instead of desktop OpenGL. What this means is that 1) we need separate cores since the current OpenGL cores available for Windows assume that desktop OpenGL will be targeted, and 2) a libretro core has to have a working OpenGL ES 2 or 3 implementation in order for it to work. This will mean that currently, cores like Quake 2/3/Doom 3 won’t work since there are no working OpenGL ES 2 codepaths in those cores. However, Mupen64plus Next and Flycast do have OpenGLES 2 codepaths.
What usecases are there for using ANGLE instead of regular OpenGL?
There are several scenarios imaginable where you would want to use ANGLE. Here are some of them –
UWP (shorthand for Universal Windows Platform) allows you to make one binary that will work on Windows Mobile 10, Windows 10 and Xbox One. The only graphics API available for UWP programs is Direct3D 11 or 12. So for OpenGL cores to work, a middleware layer like ANGLE which converts OpenGL to Direct3D is our only option. Therefore, ANGLE allows us to run OpenGL ES 2 cores on the Xbox One.
Certain graphics cards might have nonexistent OpenGL support on Windows 10 and therefore fall back to Microsoft’s reference OpenGL 1.1 drivers. This is pretty much the worst case imaginable and really limits what you can do with OpenGL on such graphics cards. Intel HD 2000/3000 series integrated GPUs are pretty much in this position. For such GPUs, ANGLE might be your only option to get any kind of acceptable level of hardware accelerated graphics support with openGL-based cores.
OpenGL driver support might be stagnating for certain graphics cards, and therefore several bugs go unresolved in their OpenGL driver implementations. ANGLE is a good way to work around that assuming you are OK with an OpenGL ES 2/3 feature set.
We will fill you in as things develop how ANGLE will fit into RetroArch’s future releases. For now, the path seems clear – separate core versions for the emulators that have viable OpenGL ES 2/3 codepaths, and separate binaries at least on Windows desktop for an ANGLE-enabled and non-ANGLE enabled version. The redist (redistributable) will also need to be updated to include the extra dynamic library dependencies.
RetroArch with Metal 2 support for macOS High Sierra users!
Up until now, we had three versions of RetroArch for macOS/OSX users:
RetroArch for OSX PowerPC (10.5) – For users with an old PowerMac or iBook/Powerbook. You should have at least Mac OS X version 10.5 (Leopard) installed in order for this version to work. Cores are packaged with this version because our buildbot does not serve fresh 32bit PowerPC cores for OSX.
RetroArch for OSX 32bit Intel (10.6) – For users with an old MacBook that has a 32bit Intel processor (for instance, 1st generation MacBook). In order to use this, you should have at least MacOS X version 10.6 (Snow Leopard) installed. Cores are packaged with this version because our buildbot does not serve fresh 32bit Intel cores for OSX.
RetroArch for macOS/OSX 64bit Intel (10.6) – This is what you are likely wanting to use on a modern Mac computer. You should have at least MacOS X/macOS version 10.7 (Lion) installed. Cores are distributed separately on our buildbot.
We are now adding a fourth one:
RetroArch for macOS 64bit Intel with Metal 2 support (10.13) – This version has all of the features of ‘RetroArch for macOS/OSX 64bit Intel’ plus a Metal 2 video driver. This version requires at least macOS 10.13 (High Sierra), a fairly modern version of macOS. For this version, we default to the Metal video driver by default.
If you have relatively modern Mac and you want to enjoy the latest in cutting edge technology, you should definitely try out this latest version. Get it by going to our Downloads page, and click on the download link below macOS High Sierra (or later).
Up until the ’10s, Mac OS X has relied on the crossplatform OpenGL API to provide hardware accelerated rendering to developers writing Mac applications. However, since 2014, there has been an industry-wide push towards lower-level APIs, and Apple in specific decided to go with its own proprietary graphics API. This API is called Metal, and was first premiered with iOS 7 and Apple A7 devices. It has since some years ago made the switch to macOS as well, and this year the API has been bumped to version 2.
Apple has announced OpenGL will be deprecated in the future, its graphics driver stuck with the dated OpenGL 4.1 spec for years now. While we regret this industry wide push away from a standardized, cross-platform graphics API, we have been forced to move with the times and instead cater to all the major graphics APIs. There is no longer the potential for one single graphics API to cater to all platforms.
With the release of RetroArch 1.7.4, we have achieved an important milestone: we now have fully functioning graphics drivers for the three major next-generation graphics APIs. This includes Khronos’ Vulkan API (added to RetroArch since 2016), Microsoft’s Direct3D 11/12 (added to RetroArch since earlier this year), and now Apple’s Metal 2 for macOS. Thanks to Hans-Kristian Arntzen’s SPIRV-Cross middleware, we can reuse the same shaders across Direct3D/Vulkan/Metal. We therefore are very close to having a universal shader specification that will work on all the major platforms.
We are now ready for a future when Apple will outright kill OpenGL support, while at the same time we have ensured that we have one common set of shaders that can be used across all these video drivers. The developer who has added Metal 2 support to RetroArch has already indicated he intends to bring this over to iOS and tvOS as well. And who knows, maybe even backwards compatibility with Metal 1 could arrive.
How complete is the Metal video driver right now?
Fairly complete. You get:
Fully functioning menu drivers. XMB, MaterialUI and RGUI should work fine.
XMB shader pipeline effect should work as expected.
You can take screenshots.
You can go into fullscreen mode.
You can use slang shaders with the Metal video driver, the same shaders that can be used with Vulkan/D3D10/D3D11/D3D12.
Things that have still yet to be added which the author is considering adding:
Recording support independent of ffmpeg.
Support for the libretro API’s RETRO_ENVIRONMENT_GET_CURRENT_SOFTWARE_FRAMEBUFFER.
Hardware renderer context support, so that libretro cores could make use of the Metal API.
General changelog
– COMMON: Support for “OEM-102” key (usually ‘\’ on Euro keyboards).
– MENU/QT/WIMP: Add option to filter extensions inside archives when adding to a playlist.
– METAL: Add screenshot support.
From at least February to mid August there was a bug on beetle-psx’s GL renderer that only affected users with AMD GPUs.
This bug was exposed when user ‘orbea’ corrected a mistake in glsm (an OpenGL state manager, made by libretro, used in beetle-psx), where it would it would hint that beetle-psx wanted a version 3.1 core profile OpenGL rendering context but, by specification, the ‘core profile’ is only from version 3.2 onward.
It is still unknown why, but after orbea’s patch, AMD GPUs would render black frames on every situation except for FMVs.
Intel and Nvidia GPUs were unaffected.
Trying to find out what was wrong was very frustrating. CodeXL and RenderDoc were briefly used in the expectation that they would point out obvious API mistakes or perform API call order analysis and give a warning e.g. “are you sure you want to change this complex colored frame for a single-colored frame and present it?”
It is unfortunate that sometimes bugs like this pop up and due to the blackbox nature of closed-source proprietary drivers, using a debugger like gdb becomes unfruitful for hobby developers when you arive at the point where your opensource the code starts calling into driver code.
Then one begins to wonder: was it one of my commits in the past? Is our code going against the OpenGL spec in some way that triggers this behavior on the typically strict spec-following AMD drivers? Is it our fault at all?
And while this bug was active, users affected by it surely grew frustrated at the lack of progress and some even got dissuaded from using beetle-psx altogether.
Eventually, in mid August, update 18.8.1 came out for AMD’s Radeon Software graphics software and that seemingly fixed the bug. Which seems to indicate towards the problem being on the AMD driver side, not in beetle-psx.
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.
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)
Picodrive should hopefully work now again on Android after notaz‘ updates.
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.
Beetle PSX – Fixed bugs (geometry updates had max width and height unset, other ones) (by albertofustinoni).
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.
– 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.
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.
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 –
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.
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful. We are using cookies to give you the best experience on our website. We collect users data for personalisation of ads, and also Google will use your personal data when you give consent on our site. Check this link to Google’s Privacy & Terms site.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
3rd Party Cookies
This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!
