Category: RetroArch

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.4

By Squarepusher –

Despite this being a point release, a couple of very important changes have been made regarding the Android port, which made me compelled to make this blog post so that I can explain some of the things that have changed.

New cores added

People always love this part – especially the Xperia Play guys who are ever struggling to hold onto ever-decreasing internal storage on their outdated devices :).

First up is a new core  – Picodrive. This has been closed-source for a fair while because notaz didn’t like guys like certain guys profiting from it through iPhone ports with donation buttons. With libretro and RetroArch now out, there s justifiable reason to open source it again since the payware/donationware guys are going to be on the run from now on.

Picodrive is a Sega Genesis/Sega CD/Sega 32X emulator especially optimized for ARM processors. It is the fastest Mega Drive emulator in existence for ARM-based devices like Android and iOS. Best of all, it comes with a 32X core which should run most games at fullspeed even on a weak ARM Cortex A8 CPU. There is only one game that has somewhat higher system requirements (Virtua Fighter 32X). An iPad Mini/2 runs this game at 56~57fps – about two FPS shy of fullspeed – your mileage may vary on how it performs on [insert your device]. It runs fullspeed on the Nvidia Shield though.

What else is new? A Stella core – this is an Atari 2600 emulator. We already bundled this for the iOS port but I guess we neglected to add it to the Android port up until now. Anyway, here it is.

Anything else besides? SNES9x mainline – ie. not the Next speedhacked version. Use this if you have a beefy device and think you can get away with a non-speedhacked version of SNES9x. It runs at fullspeed with all games on the Nvidia Shield – your mileage may vary on how it performs on your device. This version of SNES9x is more accurate than SNES9x Next- but is also a lot slower.

We also threw in the Desmume core – Nintendo DS emulator – with meancoot’s ARM JIT backend. It runs pretty much the same as the iOS port – no, it’s not going to be giving that payware closed-source emu Drastic any run for its money and it’s just thrown in for the ‘ah what the heck’ factor – its main usefulness as a libretro core is on the PC – but seeing how fast ARM hardware is catching up with even laptop Core processors, perhaps it will only take another year or two until ARM devices are at the level of a Core i5 – so we will keep it on life-support until then.

I felt it was also time to throw in Mednafen PSX – an alternative PlayStation1 emulator. Users of the PC version will know this emulator – it’s one of the most accurate open-source PS1 emus around right now. It’s always been deemed as totally unsuitable for ARM devices since it has such high system requirements – however, the Nvidia Shield is showing that there is reason for optimism. On Shield it hovers right now between 35 and 40fps with occasional spikes to 44fps. Give it some time with stuff like ARM Cortex A57 coming out and who knows if this will be able to run at fullspeed. So – it’s included by default from now in anticipation of that.

For practical purposes – it is recommended you keep using PCSX ReARMed. Don’t complain to me that this core runs too slow.

There is one other core which has been added – Instancing Viewer. This is another GL tech demo that is meant to show off instancing being done in GL. Load it up with any PNG image file and it should be rendered on a bunch of cubes – you can look at them from a firstperson perspective. You can increase the cube amount by going to RGUI->Core Options and increasing cube size. Note that the cube sizes are to the power of two – so 8 is 2 ^  meaing 256 cubes. There is no practical gameplay purpose to this right now – it’s just a Libretro GL tech demo. It might become something more useful later on.

No more static syncing by defaultWe now enable the threaded video option by default. There have been a couple of improvements to it in that it now applies adaptive jittering which should make the jittering less apparent.This option should lead to audio crackle-less gameplay on most devices. Of course, there is still the option to use static syncing and we certainly recommend its use if you know what you are doing and can set the ‘refresh rate’ in the RetroArch app to exactly match that of your display source’s refreshrate. This option just turned out to be too difficult to setup for most users and because any refresh rate mismatch in RetroArch leads to audio/video sync being incorrect, this would manifest itself in audio crackles and lead to a broken user experience.On a platform like iOS, this is simply no issue. On Android unfortunately it is. Therefore, we are playing it safe here. Upon starting up RetroArch Android for the first time, it will ask you whether you want to use threaded video or whether you want to ‘synchronize by refreshrate’. By choosing the latter option you get the old way of how things worked.

NOTE: Static syncing should work fine on nearly all libretro cores. However, there has been one annoying exception, and that is PCSX ReARMed. Certain games (like Chrono Cross, FInal Fantasy VII, Crash Bandicoot 1, and lots more) use variable refresh rates instead of running at a fixed refresh rate. This seems to play havoc with RetroArch Android’s way of doing static syncing right now (it is not a problem on iOS however). Enabling threaded video solves all these problems overnight, so we recommend that if you have your ‘forced refreshrate’ set up right, that you set ‘threaded video’ off for the PS1 fighter games like the Tekken games, Tobal games, Street Fighter games and others – ie. games that are guaranteed to run at 60Hz. For everything else, turn on threaded video for now.

Appeal to low-latency audio in Android 4.1 and up

There have been changes to the OpenSL audio driver to target the new low audio-latency capabilities of Android 4.1 and up. This should lead to much better results where the audio isn’t as hopelessly behind the video like it was in previous releases (which really wasn’t our fault but more due to us having to deal with the awful state of Android’s audio capabilities prior to 4.1 and up).

We are aware that people with sub-Android 4.0 devices (and even 4.0 itself) will likely get regressions because their Android version can’t possibly deal with low-latency audio buffer sizes. Unfortunately, there’s no getting around the fact that Android was really fundamentally broken on many different levels up to maybe 4.1 and 4.2. Things certainly have been improving a lot since then, and it makes no sense for us to keep appealing to the lowest common denominator when those phones/tablets are all going to be replaced in the near foreseeable future anyway (and they should). There’s also no point trying to upgrade most of these outdated devices (like the Xperia Play) to the latest Android version because the system requirements of newer versions of Android won’t allow for it. RAM requirements for instance have gone through the roof since Android 4.0 and up, and so it cuts off all older devices with only 512MB of RAM (and even less).

If the demand is high enough on these old outdated devices, we might introduce back a ‘high-latency audio’ option. For this release, we are trying to cater to the crowd that bought devices this year and one year ago. We believe that is the right strategy here.

NVidia Shield support

So we received an Nvidia Shield from Nvidia (two in fact – one for me, the other for Themaister) and we are certainly walking away with a higher overall impression of Android now. There are still problems, but they seem at least surmountable now.  John Carmack in a recent QuakeCon talk has spoken about some of these issues, but really, it doesn’t take a rocket scientist to fire up adb and look at Logcat and see the pages and pages of garbage collector stalls passing by to sense there is something architecturally very wrong going on with this OS from a high-performance games machine perspective. How Google is ever going to fix this and bring it at parity with iOS on most devices is frankly Google’s problem.

Returning back to Shield for a minute – I am pleased to announce I’ve gotten much more consistent runtime performance results on it than any other Android device so far. Regarding the performance of it – it’s insane – I’ve done a lot of performance tests over the past few days and so far it’s definitely the most powerful ARM-based device I’ve used.

http://t.co/nZDSmzpjec

Really, people like to deride the device for the Xbox 1 Duke-esque form factor and the high price, but really, I consider this a much better ‘micro console’ than something like Ouya or GameStick so far. (more on the Ouya stuff later). In fact, I’d say that using it as a RetroArch console alone is worth the cost for $299 – building our own RetroArch console has been a thing on my mind for sometime but really – there’s no way we’d manage to do a better job at that pricepoint than Nvidia themselves and certainly not with such hardware inside it. So let’s hope they are successful. I am certainly a believer so far.

And yeah, GPU-wise it still might not be at parity with a PS3 or 360, but CPU-wise? It slaughters a PS3 or Xbox 360. Really, I’ve been stressing this for years and it seems to have only recently been gaining traction after Mark Cerny and co have started admitting how bad the Cell was (he didn’t say that exactly but it’s fairly obvious that is what they are referring to beyond all the media training) – the per-core performance of a Cell-based CPU (this includes both Xenon CPU in 360 and Cell in PS3 itself) was something like a Pentium 4 2.4GHz CPU. It exhibited most of the same problems – deep pipelines, high penalties (to the tune of 500ms L2 cache misses – goddamn!), and to top it all off, in-order execution (and a bunch of SPUs in PS3 which are useless for general-purpose code and with too little local storage).By comparison, anything based on an ARM Cortex A15 design (like Nvidia Shield) is happily blazing past a Core 2 Duo – which has a level of IPC that a PS3 or 360 could only dream of. So really – if this is about a ‘comparison’ between the current-gen consoles and something like Shield, then the current cream of the crop of micro-consoles already wins out by a fair margin when it comes to CPU power – and then some. I have no doubt that Tegra 5 will exceed PS3 RSX/360 ATI performance levels and from there it’s basically a race to catching up with the next-gen consoles.

Long story short – this is no moneyhats – I consider this the RetroArch handheld games console I wanted to build from the onset and which none of the el-cheapo tablets/phones ever delivered.

Improved input support – analog stick support

Coinciding with the support for the Nvidia Shield gamepad, we have improved input support in a number of big ways –

Analog stick support

Some cores (like TyrQuake, SceneWalker) already have native analog stick controls – however, RetroArch Android never exposed analog stick support – up until version 0.9.9.4 now that is. Devices like the Nvidia Shield, the Xbox 360 gamepad, the Logitech Rumblepad 2 have all been preconfigured to default to ‘Dual Analog mode’ now. Libretro cores which implement ‘RETRO_DEVICE_ANALOG’ will now be able to make use of the analog sticks on an input device.

We will need more trial-and-error testing to add this functionality to more input devices. Users are encouraged to help us out in this endeavor.

ANR issues fixed (Application Not Responding)

So it turns out that the ever-reliable Google had a bug in their native activity glue code input code that was causing the input buffers to become congested and then start issuing ‘Application Not Responding’ events to the application if an input event had failed to be picked up on for over more than 5 seconds.

It seems Nvidia picked up on this issue earlier and made a blog post about it – which is the only reason I have been able to fix it for this release. According to the changelogs, Google has fixed this issue now in their code for the latest NDK version. Unfortunately for them, the latest NDK version seems to be a totally broken regression city fest where at least half of the cores that used to compile fine previously now issue ‘Internal Compiler errors’ – so I was forced to use NDK r8b either way.Speaking of which – to any and all devs reading this stuff – here are the links which hook you up – Google doesn’t seem to provide an archive of their previous NDK versions (even though they should) but luckily Nvidia still has a mirror up for it – so here goes –

https://t.co/P5poAtsS0e (NDK r8b for Linux x86_64)

https://developer.nvidia.com/content/nativeactivity-input-crashes-and-anrs-simple-fix-dangerous-bug (NativeActivity Input Crashes and ANRs: A Simple fix for a Dangerous Bug)

Input devices fixed (Xbox 360, iPega PG-9017)

Thanks to generous gifts, I was able to fix a number of input devices. First and foremost is the Xbox 360 pad – the D-pad hat controls should now be properly working. Analog stick support for DEVICE_RETRO_ANALOG has also been added.

Two modes for the iPega PG-9017 have also been added. Set iCade Profile in Settings->Input to either of the two iPega options to use them with RetroArch.

Ouya Store (??)

Some guy has registered on our forum a few days ago and has been talking about wanting to bring this over to the Ouya Store.

We don’t have an Ouya, are likely not to get one unless somebody gifts it ($99 for an Android-based Tegra 3? no thanks), and the Ouya Store policies are absolutely insane (http://forum.themaister.net/viewtopic.php?id=741&p=2) – a bunch of startup guys thinking they can pull an ‘Apple Store’ in terms of draconian app store policies. So it’s probably a good thing somebody else is going to prostitute themselves before these guys because I quite honestly wouldn’t have the patience for it.

We’ll see what comes out of it.

Anyway, version 0.9.9.4 is out now. Enjoy – we hope that people with more recent Android devices will get a much better experience now with it.  The iOS version will come a few days later – most of the work really has been on the Android version for this release.

Download Links

APK (r18) – https://anonfiles.com/file/afb0f033a3f779cb111884400406cd7b

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

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…