Coming soon – RetroArch for OpenDingux release (GCW Zero/RG 350/etc)

Written by jdgleaver

RG350 is but one of the many MIPS-based devices on the market today running OpenDingux.

OpenDingux is a Linux distribution used by a number of open source handheld gaming consoles such as the GCW-Zero, and more recently the popular RG350, RG350P and RG350M range of devices. An initial ‘experimental’ port of RetroArch for OpenDingux was made in January, but it was left unfinished. Over the past two months we have been working hard to rectify this situation.

We are pleased to announce that RetroArch now treats OpenDingux as a first-class citizen, and an official release will be included with the rollout of the new build infrastructure. While targeting the RG350M as a flagship platform (its 640×480 display offers a wealth of upscaling potential), all JZ4770-based devices should be supported. The release highlights include:

  • A reworked and well-optimised SDL-based graphics driver, with numerous features that were missing from the original experimental port (e.g. OSD notification text, graceful handling of invalid display modes, VSYNC control, fast forward support).
  • Full leverage of the hardware IPU (Image Processing Unit), with menu-based control of aspect ratio/integer scaling and image filtering methods (bicubic, bilinear, nearest neighbour).
  • A custom gamepad driver that integrates seamlessly the peculiar input configuration of OpenDingux devices (a hybrid of virtual keyboard inputs and analog sticks) and which offers full rumble support.
  • Many ‘under the hood’ enhancements such as support for battery level monitoring, memory usage reporting, a clean up of irrelevant menu entries, RGUI fixes, directory path rationalisation and a number of carefully tested compiler optimisations. This is a ‘lean and mean’ build tuned specifically for the hardware, with no unnecessary bloat.

We are launching with a modest collection of cores, each one hand-picked for performance and compatibility:

  • FB Alpha 2012 CPS-1
  • FB Alpha 2012 CPS-2
  • FB Alpha 2012 Neo Geo
  • FCEUmm
  • Gambatte
  • Genesis Plus GX
  • gpSP (Note: Currently lacks a dynarec)
  • Handy
  • Beetle PCE Fast
  • Beetle WonderSwan
  • mGBA (Note: GB/GBC/SGB content only)
  • PicoDrive
  • PokeMini
  • PrBoom
  • QuickNES
  • RACE
  • Snes9x 2005
  • Snes9x 2005 Plus
  • TyrQuake
  • VICE x64

We understand that some users may question the validity of expending two man-months of development time on such a ‘niche’ set of devices. It is the nature of RetroArch, however, that work on one platform frequently benefits others. All of the following RetroArch and core improvements have come about as a direct result of this endeavour:

– RetroArch now has a robust mechanism for implementing automatic frame-skipping based on audio buffer occupancy. This is something that stand-alone emulators have had since time immemorial, but RetroArch has always lacked (leading to the infamous ‘crackling audio’ so often reported). Auto frame-skip is a literal game changer, making a variety of previously unusable cores viable on underpowered hardware. Thus far it has been added to:

  • FB Alpha 2012 CPS-1
  • FB Alpha 2012 CPS-2
  • FB Alpha 2012 Neo Geo
  • FBNeo
  • Genesis Plus GX
  • gpSP
  • Beetle PCE Fast
  • Beetle WonderSwan
  • mGBA
  • PicoDrive
  • Snes9x 2005
  • Snes9x 2005 Plus

– As a platform without shader support, video filters are a vital part of the OpenDingux RetroArch experience. To this end, a number of new filters have been added – including several high quality LCD (and Game Boy style) effects that rival shaders, and are useful even on the desktop. In addition, many filters have been optimised intensively for maximum performance on OpenDingux, which of course reduces overheads on all platforms. And finally: OpenDingux work revealed a long-standing bug (now fixed) which disabled video filters entirely on Android.

– Snes9x 2005/Snes9x 2005 Plus has gained colour operation optimisations from Snes9x 1.60 and MIPS-specific assembly code from PocketSNES, which combine with auto frame-skip to significantly enhance performance on low end hardware. Two critical save state bugs have also been fixed.

– Our low-powered arcade cores (FB Alpha 2012 CPS-1/CPS-2/Neo Geo) have been substantially cleaned up and improved, with core option sublabels, aspect ratio correction, low pass audio filters and software-based screen rotation for devices without hardware rotation support. With auto frame-skip, even bottom-tier devices can run arcade content smoothly.

– Interframe blending in Gambatte and mGBA has been optimised, reducing performance overheads by ~70%. The same blending method has also been added to gpSP (along with optional colour correction).

– Beetle WonderSwan now has software-based screen rotation for devices without hardware rotation. In addition, colourisation palettes similar to those in Gambatte have been added for monochrome content (raw black and white is often uncomfortable to view on devices without shaders!).

– OpenDingux has rumble functionality, but we were lacking cores with which to exercise it. We therefore added rumble support to Gambatte and PrBoom, and improved the existing haptic feedback in PokeMini and TyrQuake.

This OpenDingux RetroArch port has been a passion project, born out of sheer amazement that so many of our cores run so beautifully on such limited hardware. We hope that offering a full-fat RetroArch experience will help to revitalise the community surrounding these interesting little devices. And we hope that our non-OpenDingux users will also profit from the optimisations and enhancements!

All this and more will be coming to you as part of our new range of ‘supported’ platform stable/nightly releases once the new infrastructure is about to go public. Stay tuned for more on that during the holidays!

RetroArch Roadmap for v1.7.0 and beyond

We don’t usually talk about all the behind the scenes development stuff that we do. We usually prefer to let the work speak for itself. Nevertheless, we feel compelled to share with you from now on a brief roadmap status update that basically shows what we are currently working on codebase-wise, where RA will go next, etc. We also hope this will be of use to existing upstream contributors.

Compatibility with OpenGL 1.x

From its inception, RetroArch’s OpenGL driver has targeted OpenGL 2.0 and/or later. There are a lot of people on ageing computers that don’t have a GL 2.x compliant driver. We have been putting a lot of work into modularizing the renderchain code, splitting it up from the main GL driver into their own files. This will pave the road towards a basic OpenGL 1.x renderchain which should at least work with OpenGL 1.3 and up. We might be able to target even lower versions later on, but time will tell.

Certain features this GL 1.x renderchain will not have:
* FBO support. FBOs wasn’t a thing with OpenGL until at least version 2.0 (not counting extensions). This also means no libretro GL support, so don’t expect hardware rendered cores with OpenGL 1.x.
* Shaders. Again, this is tied back to a couple of factors, one of them being the lack of FBO support which makes multi-pass shaders impossible to implement. But also, shaders are impossible in general for this 1.x mode. GL 1.x did not yet have shader support. Shaders didn’t become a thing until GL 2.x. GLSL/Cg/HLSL did not exist yet at this time and the entire rendering pipeline was fixed-function.
* There will be no fast framebuffer readback paths (in so far as that stuff is actually ‘fast’ with GL to begin with). No PBO support, which wasn’t a thing back in GL 1.x days. So expect slow screenshot taking and/or recording.
* VAOs (Vertex Array Object) and VBOs (Vertex Buffer Object) weren’t yet a thing until GL 3.x and GL 2.x respectively.

We have no idea yet when this will start working. The main issue is testing it on ancient GPUs that only have GL 1.x drivers.

Xbox OG/Xbox 360

For a long time, the Xbox OG and 360 versions of RetroArch and cores have been de-listed. This had several technical reasons, one of which being that it was a big maintenance burden and struggle to keep having to update all the separate Visual Studio solution files for these platforms. For all other platforms, we build cores using a universal Makefile, which typically contains one file (called Makefile.common) which conditionally defines which files are to be compiled in. By having to maintain some separate solution file, we need to update two files instead of one, and worse, having to start IDEs in order to edit them (or even worse), having to manually edit them with a text editor, which can tend to be error prone on top.

In order to do away with these issues, we have now reverse-engineered how we can still have a Makefile target for MSVC that uses MS’ compilers/linkers/assemblers from within the confines of a Makefile-based solution. Note that this solution does not depend on Microsoft’s nmake and uses plain make.

Now that we have accomplished being able to compile and link cores with MSVC without any MSVC solution file, we now feel the time is right to start reintroducing the Xbox OG and 360 ports.

The Xbox port work also feeds into several other things we have been working on concurrently, such as :

  • Better Direct3D support. Xbox OG will need Direct3D 8, whereas Xbox 360 needs Direct3D 9 + HLSL.
  • The latest compiler that can be used for Xbox OG is Visual Studio 2003, whereas for Xbox 360 this is Visual Studio 2010 (right now). To this end, we have updated a lot of core Makefiles to include targets for these platforms, and not just for the Xbox platforms, but PC as well.

Direct3D work – supporting more versions, etc.

In the past, we have had two separate Direct3D drivers – one for XDK (shorthand for Xbox platforms), and one for PC (Direct3D9-based). Because we intend on supporting the Xbox platforms again, we no longer want the maintenance burden of having two video drivers that essentially are similar in lots of ways. To this end, we have started modularizing the Direct3D driver so that multiple backends are possible to be implemented.

Not only is it possible to have a Direct 3D 8 / 9 codepath, but it is also possible to have separate renderchains. For instance, the Xbox 360 will be able to use the HLSL renderchain, whereas on PC the user has the option to choose between Cg (which would use the Cg renderchain), and/or HLSL (which would use the HLSL renderchain).

We also intend for there to be a fallback path to Direct 3D 8 in case your GPU and its drivers do not support Direct 3D 9 for whatever reason. Backwards compatibility is very important to us and it’s increasingly getting harder to keep supporting all of these various versions in one single codebase. These are unique challenges to which there is often not a clear-cut solution, so we have to improvise a little on the fly and do unconventional things in order to make this happen.

Windows 95

Brad Parker likes extending backwards compatibility of RetroArch to older versions of Windows, and this in turn makes our codebase more flexible so that we can keep the Xbox OG and 360 ports alive.

People might mistake this for taking up resources and time that could be better spent elsewhere, but the opposite is true – by setting up the foundation in our codebase just once, it will be automated and take care of itself from that point on. Also, there is lots of overlap between platforms. For instance,
the latest compiler that can still churn out binaries for Windows 95 is Visual Studio 2003. This incidentally happens to be the last compiler that can create binaries for Xbox OG. So already here we have overlap whenever we need to make a core compatible with MSVC 2003 and we have to create the necessary Makefile targets for it.

For Windows 95, we are thinking of defaulting to the GDI video driver instead of Direct3D since we assume that the kind of machines running Windows 95 typically would not have either a video driver with Direct 3D 9 support or a GPU that supports it to begin with. Windows 95 still supported DirectX so we should be able to default to ‘DirectInput’ as the input driver. Windows NT 3.5 will pose more of a problem here though – back then, NT did not have any DirectX support at all, so a DirectInput driver is not possible and we lack any other input driver that we could use. Windows Raw Input driver cannot work on this ancient NT version. We are not sure yet what approach we will take there.

Nevertheless, Windows 95 will be first out of the starting gates.

New hardware platforms we intend to support

We have obtained some new hardware over the past few months:

  1. NES/SNES Classic
  2. GCW Zero
  3. SteamLink

It is our intention to have this be part of our main release schedule in future releases. We understand that for a system like SNES Classic, a different approach will be required vs. just the usual ‘full fat’ version of RetroArch that people have grown accustomed to, and we will certainly be taking a long hard look at RetroArch Clover for inspiration on what we will do. Our first approach is likely going to be something similar to RetroArch Clover that ultimately piggybacks off Hakchi and which complements the main UI of the platform rather than trying to replace it.