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