Libretro GL starting from RetroArch 0.9.9

Libretro Team

By Squarepusher

RetroArch 0.9.9 (to be released later this week) will introduce an important new feature to the libretro API that I’m sure a lot of developers will be interested in.

To date, all libretro cores have used software rendered video. Sure, the frontend (RetroArch in this case) has hardware accelerated drivers (such as an OpenGL driver or a Direct3D driver), but all that really guarantees is that blitting is going through a few API functions that might (or might not ) be hardware accelerated depending on the driver supplied by the vendor. But generally speaking, libretro cores for emulators/games that depend on hardware-accelerated 3D (such as Dolphin, PCSX2, and even N64 emus) were previously impossible on RetroArch.

This is no longer the case with libretro GL. Libretro GL is not a new API – it is merely an extension to the libretro API (that doesn’t break ABI) which allows you to write OpenGL 2.0/ES 2.0 compliant code inside your libretro core.

The way this works is that at the final end of the chain inside the libretro core, everything gets rendered to an FBO (Frame Buffer Object), and this in turn will be passed back to the frontend for final processing.

Which platforms does libretro GL support right now?
The OpenGL subset we are targeting for libretro GL is either OpenGL 2.0 (on desktop) and/or OpenGL ES 2.0 (mobile and/or desktop PC in case you’re using bleeding-edge MESA drivers). This means that any platform that has at least support for either OpenGL 2.0 or OpenGL ES 2.0 should be capable of running libretro cores that depend on GL features.

The following platforms right now are supported:

  • Android
  • iOS
  • Blackberry QNX (BB10/Playbook)
  • Pandora (not tested yet)
  • PC (Windows/UNIX/OSX)

Fixed function or programmable pipeline?

With RetroArch 0.9.9, we will finally support all of the major mobile phone/tablet operating systems (except for Windows RT). This means that your libretro port can now reach a much bigger audience than just PC and/or game consoles.

All of the mobile phones/tablets out on the market today support at least OpenGL ES 2.0 (and in most cases with added extensions support). OpenGL ES 2.0 requires that you move away from deprecated fixed function GL programming. This might be an initial learning curve but the added platform support should eventually be worth it.

Note that nothing is stopping you from writing fixed function GL code – it should theoretically run on RetroArch for PC. However, this would be a bad design decision from a portability perspective since it will automatically cut off all the mobile platforms from being able to run your libretro core.

What about Direct3D / other unsupported platforms right now?

Looking at all the devices out there, it seems pretty clear that the industry as a whole has decided to throw its collective weight behind OpenGL. We therefore (for now) have made the conscious decision not to provide a similar context for Direct3D.

The downsides of this is that it automatically cuts off Xbox 360 support since Direct3D 9 is used for the XDK. I am not sure if it would make sense to eventually provide something similar for D3D or if it would be possible to somehow make a wrapper (from GL ES 2.0/GL 2.0 to D3D9) – but for now Direct3D support is out.

For the time being – PS3 support is out as well. Sony’s implementation of OpenGL (PSGL) was never made OpenGL ES 2.0-compliant – what it is currently is a mishmash of OpenGL ES 1.x and a lot of proprietary performance-related extensions. I found some undocumented functions inside that hinted at some kind of preliminary GL ES 2.0 support, but for now I’m not really confident we can make PSGL work as a GL ES 2.0 backend.

Obviously it is unfortunate that PS3 and Xbox 360 are cut off right now – the two being the only programmable pipeline consoles out there. But OpenGL ES 1.x would just be too limiting (which is what we have on PS3), and Direct3D really is only available on Xbox consoles and Windows/RT at this point – for now it doesn’t really make much sense to us to make a totally different backend just for D3D since on a Windows PC you still have the option of using OpenGL.

How do I make a libretro GL core?

Maister wrote a simple tutorial that should walk you through the steps to get started with making your own libretro GL core.

Link: Implementing a Hardware Accelerated Libretro Core

Maister also made two test cores (ModelViewer and SceneWalker) that shows off what you can do in libretro GL. These two will be the subject of a subsequent article, so stay tuned…

RetroArch v0.9.9 Coming Soon

hizzk

It’s almost time for a new release of RetroArch, and there a number of big changes coming up. First of all, RetroArch 0.9.9 will mark the release of RetroArch on iOS and Blackberry 10/Playbook Tablet OS. These ports were made possible with the help of CatalystG and meancoot, respectively – for which many thanks. The iOS port will be released on Cydia and on our forum. It is possible to run it on a non-jailbroken device – but it will require that you are able to code-sign yourself (ie. if you are a registered Apple developer with the ability to code sign).

PCSX ReARMed on iOS

For iOS, perhaps the single biggest hurdle was getting PCSX-ReARMed working, which required notaz to rewrite much of the assembly code to work with Apple’s ancient GAS assembler version (big thanks to him for that!). With that completed, this should be the first time PCSX ReARMed will appear on iOS – through RetroArch.

RGUI

Elsewhere, Themaister and Squarepusher have been toiling away at a million other features, including the promotion of RGUI to a robust and feature-filled in-game menu system for the platforms that otherwise lacked such a thing, particularly the PC platform (i.e., Windows, Mac OS X and Linux). From its humble beginnings with the Gamecube/Wii port, RGUI now provides a way to change emulation cores, swap out ROMs, configure shaders and more, all without leaving the fullscreen gaming interface:

rgui

Cave Story (NXEngine)

ToadKing and Squarepusher have also done some work on ‘uncrippling’ Cave Story (ie. NXEngine). Previously, the file I/O would make it unbearably slow on consoles. This has mostly been fixed now that everything is pre-cached into RAM at initial startup. There are still some incidental dips to 59.50fps and 59.2fps, though, which causes some sound stuttering. The cause of these dips is still unknown but we feel that–compared to before–NXEngine can be safely released on consoles now without being an utter embarrassment. “Xbox 1/360 will require some further patching up of the codebase because NX Engine did some global symbol table trickery and the MSVC linkers have the (oh so ‘smart’) tendency to ‘strip away’ unreferenced symbols as an ‘optimization feature’ with no way to stop it from doing that (even /ref:noopt doesn’t help there),” Squarepusher noted.

TyrQuake

The port of TyrQuake will also be bundled with RetroArch 0.9.9. A lot of work went into making it work on Xbox 1 and Xbox 360 – including making the C99 codebase cross-compilable as C++98 and (for Xbox 1) resorting to a hacked-up template ‘typeof’ implementation (ye, don’t ask) for MSVC 2003. “I also threw in some additional ‘hackish’ features like ‘dither filtering’ (borrowed it from some guy that implemented it earlier) – this more or less looks like the Unreal 1 software renderer’s ‘bilinear filtering’ implementation,” Squarepusher said. “There is also a third-person chase cam view and a way to ‘lerp’ the animations (ie. add key-frame interpolation in order to make the animation of enemy models look smoother and have more frames of animation than they originally did).”

“I plan to eventually rebase the TyrQuake port and push it upstream to the original authors (ie. the maintainers of TyrQuake) – I did a lot of careless code rewriting that I’ll be sure to avoid for the rebase,” he added.

Shaders

There has been a major overhaul of the way shaders are handled, which has paved the way for advanced, multipass shaders that can be easily setup by end users without needing to tinker with any code. As part of these changes, the old XML/GLSL shaders with fixed-pipeline functions have been deprecated, but will still work just fine. In the future, we ask that interested shader authors try to stick to the multiplatform Cg format when possible. The GLSL/GLES formats will still be supported for compatibility with platforms that don’t support Nvidia’s Cg Toolkit, such as Android and iOS, and Cg shaders can be converted to these legacy formats programmatically using Themaister’s cg2glsl python script.

A couple of examples of newly written shaders that utilize some of the recently added features are Themaister’s NTSC Composite shader, which should work well on any libretro core, and Harlequin’s Gameboy shader:

There is no firm release date for v0.9.9, but if you would like to try any of these features out or get involved in the development, you can grab the code from git and compile it yourself for your platform of choice. If you have any questions about these features or RetroArch/libretro in general, stop by the libretro forums or drop by #retroarch on Freenode IRC.

Discuss this post