Category: Libretro

RetroArch 0.9.9.7 upcoming + progress

By Squarepusher

Here is what we have been spending our time on since the last release – and some more project-related progress.

RetroArch 0.9.9.7

Another new version is upcoming.  No, this is not yet the new release with the Nintendo 64 core. No, that won’t be bundled until RetroArch 1.0. In the meantime, there will be a lot more incremental point updates until we arrive at that stage. But there will still be plenty of good stuff in this new release, such as:

  • Dinothawr included (for PC/Android/iOS for now) – see below
  • VBA Next – big performance improvements (see below)
  • VBA-M libretro port (see below)
  • Picodrive updates – improved 32X emulation (see below)
  • Initial per-core config support for Android
  • And more…

Dinothawr – first libretro game built from scratch

Hans-Kristian Arntzen (Themaister) and Agnes Heyer have made a Kickle Kubickle-style game in their spare time that looks a lot like a 16bit Super Nintendo game from the early to mid ’90s.  It has quite simple gameplay mechanics – you control a dinosaur from a top-down perspective that has to free his enfrozen dinosaur friends by pushing them onto lava. It has a rolling soundtrack that is very soothing to the ear and has a definite distinctive style.

Next to the game being nominated at the Norwegian Game Awards 2013, this game is notable in another way – it is perhaps the first example of a game written from scratch for the libretro API. It is written in C++11 and will be ported to all platforms that have a compiler in their toolchain that allows compiling for that standard.

Dinothawr will be bundled with RetroArch Android/iOS starting from version 0.9.9.7. I will have to see how feasible a port to the consoles (and Blackberry) will turn out to be. If C++11 proves to be a problem on those platforms I might have to deprecate the codebase to C++03 or C++98.

VBA Next performance improvements

VBA Next is a fork of VBA-M with notable improvements in performance. This week it will gain an even bigger performance upgrade thanks to the work of bgK. VBA’s rendering code has always been needlessly inefficient and slow due to its pixel-per-pixel loops. bgK has made a drastic improvement in speed by changing gfxDrawTextScreen to a tile-based rendering approach. This has pushed Final Fantasy 5/6 to fullspeed on PS3/360 and has made many of the games that would not be playable at fullspeed on the Nintendo Wii now run at fullspeed.

Expect similar improvements on other platforms – the iPad Mini/2 can now play games like Sonic Advance 1/2/Mario Advance 1 at fullspeed whereas previously it would be stuck at 52fps or so. Android devices will benefit from the performance improvements across the board too.

VBA-M – libretro port pushed upstream

This is a new libretro port of VBA-M. There have been quite a few improvements made to the codebase since VBA Next was originally forked from VBA-M. This port (which is GBA-only for the time) has been pushed upstream to the official Sourceforge repository. The tiled rendering rewrite of gfxDrawTextScreen (by bgK) has also been pushed upstream – it can be optionally compiled in by defining -DTILED_RENDERING.

There are quite a few changes between VBA-M libretro vs. VBA-M standalone:

  • Built-in vbaover.ini file – vbaover.ini not necessary
  • Savestates/SRAM/battery is memory stream-based instead of file I/O based – this drastically speeds up read/writing. Plus it allows for nice things like real-time rewind.
  • It is GBA-only for now – GB/GBC/SGB support has not been built in (I am unsure if this would even matter).
  • flush_samples has been rewritten to be more optimal – assume that we will always use the length parameter of the audio driver write method instead of catering to old legacy audio drivers – don’t block inside flush_samples
  • SRAM/Battery autodetection/handling was broken by design in Visual Boy Advance/VBA-M – this has been corrected. There is also a way of converting back and forth between ‘fixed’ VBA Next-style saves and VBA-M saves (compile gbaconv.c as a separate program – available in the repository).
  • All the other advantages of a libretro port

MAME 2010 and MAME 2013

R-Type (a fellow contributor to the project) has done some noteworthy stuff as of late. I have worked together with him on libretro ports of MAME 2010 (MAME 0.139) and mainline MAME (0.150). Right now, this libretro port only caters to PC and Android so far – other platforms will have to be looked at in time.

MAME 2013 (MAME 0.150) should be fully playable right now on Linux and Windows. Here are some features:

  • No SDL anywhere. Uses libco for threading.
  • No stupid “web server” baked in for “frontend duties”. Quite easily the most stupid decision in emu land ever this year. I didn’t even want to believe this is what they did but they did (for 0.150). Let’s just hope this won’t become ever harder to “bake out” from 0.150 and up – it is stupid shit like this that leads to projects getting forked, libav/ffmpeg-style.
  • We autoconfigure a great deal of games with ‘proper’ joypad controls. For instance – Killer Instinct 1/2 default to SNES-style layout on the RetroPad, ditto for the Mortal Kombat games. Tekken 1/2/3/Tag/Soul Calibur/Soul Edge all have their controls mapped the same as a default PlayStation-style pad. These are by no means the only games we have autoconfigured, however. If the default preconfigured controls are not to your liking, you can also use MAME’s OSD system (triggered by pressing RetroPad R2) to reconfigure the controls to your liking – it will save the controller changes in a MAME config file and this will be applied at startup when launching the MAME core.
  • OSD is available and fully functional (triggered by RetroPad R2). There is also RetroKeyboard and RetroMouse support.
  • Cave SH3 drivers have been baked in again. In case some kind of shitstorm erupts over this – here is my stance. Cave officially exited the arcade game business – they have no leg to stand on with regard to “demanding this stuff be not included”. Preservation of arcade hardware can not just have arbitrary “end dates” just because certain manufacturers don’t like it. There is no more money to be made in arcades to begin with – find other viable solutions for your ailing business instead of falling back to a scene (arcade scene) that is all but six feet under (and counting). And no, iOS ports don’t count and are a mere shadow of their former arcade selves. Touch controls are a total disgrace to bullet hell shooters.

It should be pretty easy to sync with MAME mainline. A MESS/UME port might also be considered in the future.

Here is a video somebody took of Ridge Racer running nearly at fullspeed on his Core i5 PC with a CRT shader enabled. I assume if he got a somewhat higher-specced PC this game would be plain sailing at fullspeed. System requirements have gone up even further still since 0.139 (MAME 2010) though – so there is no telling if performance will decrease even more over time.

Let me just reiterate that these games run like a dream on RetroArch. It is quite something to see Killer Instinct 1/2/Tekken Tag/Soul Calibur and co run on MAME libretro with RetroArch.

Picodrive updates

Picodrive has received numerous improvements to its 32X emulation code since it was first launched earlier sometime ago on iOS/Android.  Lasers should now show up in Star Wars Arcade on ARM-based systems, games like Metal Head should now work, and more besides.

Gifts

Thankfully, gifts are still coming in. For instance, an Xperia Play has arrived – so I can finally develop for this thing. I have found that the thing can be made to run quite well – at least on-par with a Gamecube/Pandora 1GHz model. You just need to set refresh rate to 59.19Hz, disable threaded video, and (most importantly) set audio latency to 128ms. With these settings, you should be able to play most cores at fullspeed except for SNES9x Next/SNES9x and other more demanding cores like VBA Next.

The RetroArch Android port has received some Xperia Play-specific additions – for instance, it now autoconfigures these settings at startup when running RetroArch Android for the first time on the device. There are still some input problems to do with touching certain regions of the gamepad – which for some reason will trigger AKEYCODE_BACK. I think I can overcome these issues by writing a custom Native Activity implementation explicitly for Xperia Play and then just preventing AKEYCODE_BACK from exiting the application altogether.

I was also gifted an Ouya by developer d6s (author of the Nostalgia app on Ouya) and ToadKing was gifted an Ouya by develper littleguy (from the Mupen64 AE project). We should now have the means to develop and publish the RetroArch app inhouse. We will let you know when we are finally at that stage – it involves transferring over some credentials from the previous custodian. I will also implement hooks to the Nostalgia app so that the author of that app (d6s) can have an easier time launching RetroArch games from his frontend.

Other gifts which will be arriving – a Raspberry Pi by libretro forum member Vanfanel for one, and we also got approached by iBen who offered sending an iBen L1. I will inform people when that happens.

All these gifts are for the sole purpose of improving RetroArch hardware/peripheral support and to ensure that these devices are configured properly out of the box (since for most of these Android devices it unfortunately requires tinkering with audio/video settings to get it running just right).

Surface RT – RetroArch RT port

I am also occasionally still taking money out of my own pocket to allow the project to grow. For instance, next week I will be buying one of these Microsoft Surface RT tablets for the sole purpose of bringing RetroArch over to Windows 8/Metro/RT/Phone.  Yes, I know the Surface RT was a big flop, that it only has a puny Tegra 3 SoC, that the successor is already unveiled and that it doesn’t even allow for dynarecs. I am only interested in the device for the sole purpose of adding yet another platform under RetroArch’s belt.

It will also be a good opportunity to try to  use ANGLE as a wrapper for OpenGL ES 2 so that we can bring libretro GL ports over to Surface RT, Phone, Xbox 360 without having to write some kind of Direct 3D 9/11 interface around the libretro API which – really – we really don’t want to do. ANGLE is already used on Windows for translating WebGL calls to Direct 3D 9/11, so it already has been stress-tested well to that degree. Now here is hoping that API overhead is negligible.

RetroArch Android 0.9.9.5

By Squarepusher –

Another point release – and a lot more to talk about again.

New cores

So given the power of the Shield, we decided to dust off some libretro cores that have previously only been used for PC. bsnes/higan Performance core was high on our list. Thankfully, the nVidia Shield puts up quite the show.

I have done some extensive performance tests with bsnes/higan v0.92 on RetroArch Android (on the Shield) and I can confirm that every single non-coprocessor game runs at fullspeed and runs great. That means – every game that is not an SA-1/SuperFX/DSP/Cx4-coprocessor enhanced game will run just fine with bsnes/higan on a Shield.

bsnes/higan Balanced core according to maister did around 57fps with Zelda 3 – so *nearly fullspeed* but obviously Performance core is a better candidate for now on the Shield. Perhaps with the Shield 2 (Tegra 5?) we could expect co-processor games to run at fullspeed on the Performance core and for every non-coprocessor game to run at fullspeed on the Balanced core.

Also, need I remind you – yes, battery usage with bsnes will be higher than with any other SNES core. And no, unlike bsnes/higan on the PC, you can just use your trusty old .SFC/.SMC ROMs on it.

UI

I’m gradually coming around to the realization that the people badmouthing the current UI are, in fact, somewhat correct. However, this complaint I feel is valid only when it comes to the Android frontend which does indeed suck. So I have begun to restructure it all and in this release you can start seeing the first fruits of that labor. It’s a lot better organized now and on a microconsole like the Ouya/Shield it shouldn’t require you to leave your fingers off the gamepad and reach for touchscreen or the mouse in order to reach certain parts of the UI.

TV Mode

Given that microconsoles seem to be all the rage now – I thought adding in this mode from the iOS port would be nice. What this does, is that it boots you straight into RGUI. From there, you can navigate the menu with your gamepad and launch cores/games from there. The best part about RGUI (which could always be toggled from an overlay or from a gamepad that has a menu button BTW) is that it has a ‘history list’. It keeps a history of every game you have played – and you can select that game from the history list and it will instantly switch to that game. This mode is even more convenient when you have “Auto-load state” and “Auto-save state” turned on so that it instantly starts again at the point where you last left off.

Also, this “History list” is also going to be making an appearance in the Android frontend UI at some point for convenience.

Ouya

Somebody has offered to send an Ouya. We’ll see if it arrives here safely. If so, I’ll assume control over the RetroArch Ouya release as well along with Moonlighting and make sure that it’s a decent user experience on Ouya.

Download links

APK (r19) – http://themaister.net/retroarch-dl/android/org.retroarch.browser.RetroArch.r19.apk

Google Play – https://play.google.com/store/apps/details?id=org.retroarch&hl=en

BTW – the iOS port will come a day later. It will have Picodrive and all updated cores and changes.

Libretro ffmpeg

By Squarepusher

Lion King running on libretro ffmpeg with around 5/6 shaders stacked - hence the low framerate (my GPU can't keep up)

Lion King running on libretro ffmpeg with around 5/6 shaders stacked – hence the low framerate (my GPU can’t keep up)

This core isn’t particularly new – maister has been dabbling on/off with a libretro ffmpeg port for a good two years now. The problem was that up until now it was never really particularly useful except for morbid curiosity.

The main achilles heel has always been that video rendering was software-based through libretro. Software-rendered video is still awfully slow compared to hardware-accelerated rendering, and launching a movie player with no hardware acceleration would definitely not compare favorably to pre-existing media players.

Now that it has made the leap to libretro GL, its usefulness has increased by a lot. The most noteworthy aspect of this core is that there is a core option enabling/disabling temporal interpolation. Through motion blur it will ‘fake’ a higher framerate in movies (fake 60fps).

The Matrix running on libretro ffmpeg with waterpaint-mudlord shader - looks like The Matrix meets Waking Life/A Scanner Darkly.

The Matrix running on libretro ffmpeg with waterpaint-mudlord shader – looks like The Matrix meets Waking Life/A Scanner Darkly. (in case you think the video quality leaves much to be desired – remember that the input source here is a low-quality SD Xvid video circa mid ’00s.

Another very appealing aspect of the ffmpeg libretro core is (of course) the mere virtue of it running inside RetroArch, which means for ports that have shader support, shader passes can be applied ontop of the image. We’re pretty confident no other movie player right now is offering 8-pass shader stacking right now – never mind it being dynamically configurable from a built-in menu. Also included (an option of most interest to otakus who like to watch anime) is ASS subtitle support.

Despite the very cool nature of this ffmpeg port, it should be noted that this is fundamentally a very backwards way of implementing a movie player. While most movie players are high-latency affairs that depend on buffering and advanced A/V synchronization strategies, this ffmpeg core instead depends on a low-latency frontend (ie. RetroArch in this case) in order to deliver good audio and video. Something which might simply be too tall an order on Android given the high-latency audio/video drivers on that platform.

Terminator 1 with bsnes-gamma-ramp applied. What you can't see is how smooth this looks with temporal interpolation turned on.

Terminator 1 with bsnes-gamma-ramp applied. What you can’t see is how smooth this looks with temporal interpolation turned on.

An attempt will be made by me to get this running on mobiles and anything in fact supporting libretro GL – this might have to involve baking in ffmpeg as a static library since on the mobile platforms ffmpeg is not available or can be installed as a dependency.

All in all, the temporal interpolation option really makes a big difference in the movies I’ve tried it with, and overall it’s an exciting and promising indicator that libretro doesn’t necessarily have to be confined to merely emulators or games.

RetroArch v0.9.9 Released – where to get it on each platform

RetroArch v0.9.9 has officially been rolled out on all platform targets.

The new platforms that are supported with this release of RetroArch are as follows:

  • iOS (both jailbroken and non-jailbroken – non-jailbroken requires that you are a registered developer and can compile your own copy of RetroArch + cores)
  • Blackberry 10
  • Blackberry Playbook Tablet OS

The other platforms which are already supported by the RetroArch/libretro projects have all received updates (with some pretty extensive changes – more on that in an upcoming blog post).

WHERE TO GET IT

Windows: New users can download 32- and 64-bit flavors of RetroArch and RetroArch-Phoenix from Themaister’s site:

http://themaister.net/retroarch.html

Existing users can/should download the new version through RetroArch-Phoenix’s built-in ‘RetroArch Updater’ utility. (this is the preferred update method for existing users to save massive bandwidth!)

Mac OS X users can download hunterk’s builds from this post on the libretro forum:

http://forum.themaister.net/viewtopic.php?pid=459#p459

Debian/Ubuntu/Mint users can add hunterk’s Launchpad PPA repository to their Synaptic/apt sources:

https://launchpad.net/~hunter-kaller/+archive/ppa

iOS users can find RetroArch iOS in one of Cydia’s default repositories – ZodTTD & MacCiti.

You can also add our own Cydia repository in order to get it, located at:

http://themaister.net/cydia

Most cores will work with both tethered and untethered jailbreaks, but cores that require the use of a dynamic recompiler (dynarec; DeSmuME and PCSX-ReARMed) will require a full, untethered jailbreak to function.

Android users can get the latest version from the Google Play Store. Xperia play controls seem to be wonky, but we hope to have that fixed very soon.

Wii users should use this package:

https://anonfiles.com/file/4536ac12f0071a397b2f1d70672814cf

Blackberry Playbook users should use this package:

http://themaister.net/retroarch-dl/blackberry/playbook/RetroArch-1_0_0_1.bar

Blackberry 10 users should use this package:

http://themaister.net/retroarch-dl/blackberry/bb10/RetroArch-Cascades-1_0_0_1.bar

PS3 users can get the DEX and CEX versions from the usual sources.

Xbox1 and Xbox360 users can get their respective versions from the usual sources.

OpenPandora users can get builds from lifning’s repo:

http://repo.openpandora.org/?page=detail&app=retroarch.lifning.001

Libretro GL – SceneWalker

The SceneWalker with the Silent Hill 3 Chapel model loaded in. This entire map mostly works correctly.

The SceneWalker with the Silent Hill 3 Chapel model loaded in. This entire map mostly works correctly.

By Squarepusher

Here is the second tech demo by maister made to showcase what is possible with libretro GL. SceneWalker is a heavily modified version of ModelViewer.

Instead of loading ‘character models’, its main purpose is to load in ‘scene models’. Once loaded in, you can then walk around these environments from a first-person perspective. It’s possible to move through environments using either the D-pad and/or the analog sticks. Pressing RetroPad B button allows you to jump – this comes in handy with some models where certain obstacles are preventing you from fully traversing the environment.

A great deal of environments already work within this SceneWalker app – the initial ‘placement’ of your starting position is currently a problem in some models since it is possible for you to be ‘dropped’ inside a void space. This happens for instance with the ‘Devil May Cry 4’ street model which makes it impossible to walk around that map.

Other maps (such as Silent Hill 3’s chapel) work fine on the other hand.

Basic collision detection and gravity has been implemented – it mostly works the part for most models.

Below you’ll find some screenshots of some models that we have loaded into this SceneWalker.

This is the map 'Amnesia Fields' from the PSP version of Tekken 5: Dark Resurrection. The skybox is missing from this model but everything seems to more or less work correctly. There are some popup issues that might or might not be overcome in the future.

This is the map ‘Amnesia Fields’ from the PSP version of Tekken 5: Dark Resurrection. The skybox is missing from this model but everything seems to more or less work correctly. There are some popup issues that might or might not be overcome in the future.

This is the Twisted Corridor map from Alice In Wonderland. There are plenty of places here where if you don't carefully jump on the platforms you can fall into the void.

This is the Twisted Corridor map from Alice In Wonderland. There are plenty of places here where if you don’t carefully jump on the platforms you can fall into the void.

A pub scene from the MMO game Vindictus rendered inside the SceneWalker.

A pub scene from the MMO game Vindictus rendered inside the SceneWalker.

This is the police station main hall scene from Resident Evil: Umbrella Chronicles. The model uses DDS textures which are currently a stub - hence why there are no textures right now when showing this model.

This is the police station main hall scene from Resident Evil: Umbrella Chronicles. The model uses DDS textures which are currently a stub – hence why there are no textures right now when showing this model.

Platforms

Scene Walker right now runs on:

  • PC (Windows/UNIX/OSX)
  • Android
  • iOS
  • Blackberry QNX (BB10/Playbook)

The maximum supported internal resolution at which you can render the models depends on the platform you’re running Scene Walker on. On the mobile platforms we have consciously decided to set the maximum supported resolution at 1024×768 – this should be the native resolution of the iPad 2/iPad Mini and it is doubtful that even on a powerful tablet you’d have much need for 1080p internal resolution anyway.

On PC 1920×1600 is the maximum internal resolution at which you can render these models.

Like all the non-GL based libretro cores, you can apply any amount of shaders that you want.

Scene Model links

I’m not exactly sure how hard-ball game developers are when it comes to these models – but anyways, there is a lot of source material you can find on the Internet.

Some places that supply them is DeviantArt (search for DeviantArt + XNALara-  that should show up a bunch).

Another site that I’ve found includes a lot of useful models is this one (http://thefree3dmodels.com/). Make sure that when downloading a model form there, that it says ‘OBJ’ or something similar. Models that are not in this format can’t be expected to run right now.

Libretro GL – Modelviewer

By Squarepusher

As a showcase for libretro GL, maister made two quite nice libretro cores that should appeal to demo coders and traditional game developers alike.

Model Viewer

I encouraged Maister to do a libretro GL port of an old project he made a year ago (Model Viewer) as a showcase for libretro GL.

The Model Viewer takes ‘Wavefront’ object models as the ‘ROM’. it then displays these models inside a bare 3D environment.

It is possible to adjust the camera and rotate the model, zoom it in/out, etc.

Right now it is still in a basic phase but you’ll find a great amount of models that you can find on sites like Deviant Art and Free 3D Models (http://thefree3dmodels.com/) should already run unedited.

NOTE: Models that depend on DDS textures (DirectDraw Surface) will appear in the Model Viewer as ‘flat shaded’ for the moment since DDS support is currently a stub.

Below I’ll showcase some models being rendered inside the Model Viewer. Search around for some of these models yourself (some key terms being ‘XNA Lara’ and/or ‘3D Studio Max’). If the model comes with an OBJ/MTL file and a couple of PNG/JPG/TGA images it should more or less work barring some exceptions. (.mesh based models are not supported right now)

The Final Fantasy XIII Vanille model mostly appears correctly in the Model viewer except for a few minor details

The Final Fantasy XIII Vanille model mostly appears correctly in the Model viewer except for a few minor details

Here you see Lightning displayed in the Modelviewer with lots of shader passes applied. Most apparent shader here is the Waterpaint mudlord shader which gives the model a painterly look.

Here you see Lightning displayed in the Modelviewer with lots of shader passes applied. Most apparent shader here is the Waterpaint mudlord shader which gives the model a painterly look.

Modelviewer showin the Final Fantasy X-II Rikku model.

Modelviewer showing the Final Fantasy X-II Rikku model.

Bryan Fury from Tekken Tag Tournament 1 - looks more or less like Bryan - some hue issues here and there.

Bryan Fury from Tekken Tag Tournament 1 – looks more or less like Bryan – some hue issues here and there.

Marshall Law model from Tekken 6

Marshall Law model from Tekken 6

Platforms

Model Viewer right now runs on:

  • PC (Windows/UNIX/OSX)
  • Android
  • iOS
  • Blackberry QNX (BB10/Playbook)

The maximum supported internal resolution at which you can render the models depends on the platform you’re running Model Viewer on. On the mobile platforms we have consciously decided to set the maximum supported resolution at 1024×768 – this should be the native resolution of the iPad 2/iPad Mini and it is doubtful that even on a powerful tablet you’d have much need for 1080p internal resolution anyway.

On PC 1920×1600 is the maximum internal resolution at which you can render these models.

Like all the non-GL based libretro cores, you can apply any amount of shaders that you want.

Model links

I’m not exactly sure how hard-ball game developers are when it comes to these models – but anyways, there is a lot of source material you can find on the Internet.

Some places that supply them is DeviantArt (search for DeviantArt + XNALara-  that should show up a bunch).

Another site that I’ve found includes a lot of useful models is this one (http://thefree3dmodels.com/). Make sure that when downloading a model form there, that it says ‘OBJ’ or something similar. Models that are not in this format can’t be expected to run right now.

Libretro GL starting from RetroArch 0.9.9

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…