Category: Development

Android development and the future of RetroX

I wanted to share some thoughts about the recent bad news of LaunchBox for Android being discontinued. I’ve read their forum post and wow, what they describe is exactly what I have been dealing with Android all these years while developing RetroX for it.

I decided to write this post before some questions arrive, reading the LaunchBox forum on this topic can make the future look bad, but I want to tell you why RetroX is not and should not be affected by those issues. I strongly recommend you to read their forum post before reading what comes below.

https://forums.launchbox-app.com/topic/54393-the-state-of-launchbox-on-android

Honestly I was expecting something like this to happen, only that I was surprised that it actually happened. Making an emulator launcher is something that one can do in a few hours if you have some experience in Android or a few days if you are new to the platform. Getting results for launching 8 and 16 bit console games is relatively quick. The problem starts when you want to go beyond that and you start dealing with Android limitations, fragmentation, corner cases, emulation of computer systems and the list goes on and on.

Making development economically sustainable

When I saw the LaunchBox releases it was like seeing the initial days of RetroX and I knew all the road and its difficulties that would come ahead. Their price point (5 dollars) for a lifetime license rang a bell on me, they should sell a lot of licenses or they should let their PC app fund the Android development, there was no other way to do it.

Sadly, the mobile market set a bad precedent when people started selling apps as cheap as 1 dollar, that made people get used to get great apps at a ridiculous price. People learned to associate Android (and iOS) with cheap apps. Of course some companies succeed at that, but they first needed to throw a lot of money on marketing force to get people’s attention. Not all developers can do that, including me.

On Jason’s words:

It doesn’t really make sense for us to be spending half of our development time on the project, while only making a 5% return

I became aware of this issue in 2018. As RetroX grew and Android started changing for bad I realized that having cheap lifetime licenses would not be enough to continue developing RetroX and to continue running the associated services (support, infrastructure, etc). RetroX would have died this year (2020) following that trend. I already have seen other front ends being abandoned because of this, and I didn’t want it to happen to RetroX, so I took the unpopular decision to use a subscription based model to make sure that RetroX will continue growing for many years to come. Some people got mad about this but now LaunchBox is a good example of what could have happened with RetroX.

Android development

Android is a hostile environment for software developers. Google has total control of this environment and they just don’t care about breaking apps. I also have to add that they have been really erratic in some areas like hardware acceleration, permissions and the worst of all, storage policies. And this will not change for the better. More on that later.

Play Store and software distribution

What Jason says about the Store is quite true:

The Google Play Store is really the only viable way to release apps on Android, and red tape is everywhere

Fortunately I didn’t need to be on the Store to get where I am today (thanks Stuart Law and John Logie for that), but that’s the reality of the Store and now I’m glad that Google rejected RetroX.

It’s not only about their arbitrary restrictions or the impossible-to-contact-a-human policy, but there is a worse problem: Random users are harsh with developers. If they don’t understand the app – which is more common that what one would think – they just throw shit at you, it’s just a matter of having a look at their uninformed comments on some apps.

I wouldn’t give names but once I started talking with a developer of another frontend and he had fallen into depression after receiving the feedback from the users in the Store. I’ve checked today and his app hasn’t been updated since 2018 and his public activity stopped in 2017. His app was quite good but random users… they are nasty.

Being out of the Store was not my decision but it was a fortunate consequence of the red tape on there. I rarely get random users, most of you tried RetroX because a trusted friend or family recommend it, and I know that every person that purchases a license do it because they liked the app and they will tell their friends about it with confidence. I think one to one recommendations is a lot better than getting random people finding your app in the Store among the sea of 1 dollar apps and throwing shit back to you.

Future restrictions on Android

I want to quote Jason fully in this topic:

There are major concerns regarding the future of emulation on Android at all. Google has begun severely restricting the ability to share files between applications for security reasons, and it’s already affecting users who are running Android 11. They’ve been pushing for these changes for quite a while now, but they’re a poor solution and they wreak havoc on emulation, because they disallow sending ROM files from a frontend to an emulator, amongst other things. This was the straw that broke the camel’s back for us.

First some background about this: All frontends on Android run an emulator that was installed manually by the user, and they are separate apps developed by different developers. Because of that, they can’t share their files. And yes, if Google does what Jason says these frontends will all stop working unless they find an obscure way to bypass those restrictions, but bypassing restrictions will risk them to be thrown out of the Store by Google at any moment.

For your peace, RetroX doesn’t work this way and it won’t be affected for such a change.

I’ve always said that RetroX is not a frontend, but it’s easier to use that name for people to understand the app. Why is not just a frontend? Because In RetroX I maintain the main app and the emulators, because for a tight integration I need to change the emulators to be “RetroX compatible”. That has a bad and a good side: The bad side is that adding more emulators or updating them require tons of work, the good side is that they are fully integrated and tested against RetroX. Being both the app and the emulators being distributed (signed) by me, they can share the files with no restrictions, so the changes announced by Google will not affect RetroX.

Emulator support

Now, you may say with funded reasons that “hey Franco, but look at N64, Dreamcast and PSP, they haven’t been updated, and where is C64?”. Yes, you are right, that’s exactly the bad side of having to modify the emulators to make them run great with RetroX. Their codebase is all different and worse, some of them are very old and the code is a mess to deal with, that is a showstopper to work on those emulators. For example C64 today runs with RetroX but the controls, keyboard support, cloud saves etc, is a big work that hasn’t been completed. Dreamcast.. they changed a lot of files and the integration needs to be done, and the story goes on and on.

Compare this to Saturn. It fought back, it wasn’t easy, but I finally did it. What’s the difference? The difference is that the Saturn emulators run inside RetroArch, so I integrated RetroArch first and I don’t need to do that again to add more emulators like the Saturn ones. And that’s the direction I want to take from now on. If possible all the emulators will be added through RetroArch were some cool additions has been made like live borders / backgrounds, and recently the activation of their rewind / forward feature. And there is still a lot of interesting stuff to be done there.

Currently I’m in a personal campaign to check what emulators can be integrated through RetroArch, now that I know their code better I’m able to add some required features like virtual keyboards and such.

Plans for the future

After moving more emulators to RetroArch I really like to put a foot outside Android. Don’t get me wrong, the main app will continue to be targeted to Android, only that I want RetroX to exist on desktop systems as well. Initially it will be Linux based but gradually I want to add support for OSX and Windows as well. This will open the door to a wide range of opportunities, I would love to have a bootable image of RetroX for Single Board Computers and such.

Even with the Android and its crazyness I see a bright future for RetroX for many years to come, so thanks for sharing the ride with me.

Automapped controllers and touchscreen overlays

From 2.9.0 you can just grab any controller and start playing. Another player is joining? Just grab another controller, press a button and start playing. ONLY if your gamepad has a weird configuration you may need to teach RetroX how your button works (map the buttons). The good thing is that you only need to do it once, and RetroX will pick that config up any time you use that kind of controller.

When RetroX started in 2012 there was no standard for controller buttons on Android, in fact, there was no controllers for Android, you had to use a PC gamepad connected via USB to your TV Box. In my case I used a PS2 to USB adapter to connect a wired PS2 gamepad to my TV Box. As buttons weren’t standard, all controllers sent different events when you pressed a button, and they also had different layout for A/B/X/Y… if they had something like that (PS2 don’t). Some PC controllers had an “A” button and sent a BUTTON_A event when pressed, but others sent a BUTTON_B even when pressing the button in that same location, this was because some controllers followed the SNES convention of ABXY while others followed the Xbox convention for those button, which is inverted (BAYX)!  Other controllers like the PS2 one sent events like BUTTON_3 or even BUTTON_9 if you pressed the SELECT button. On that reality you had to map the buttons and that’s why I added the Gamepad button mapping screen in the first place.

To make things worse, there was no reliable way to pass that info to the emulators so I finally had to assign each gamepad to each player for it to work. The bad thing was that if you assigned a controller to player 1 and picked another controller, you had to switch it in RetroX to use it as player 1. Not a good thing.

Fortunately as time passed Android defined an Xbox type of layout for their controllers and events like BUTTON_A, BUTTON_SELECT , BUTTON_START and others became standard. Most controllers use that standard today and RetroX assumes that’s your configuration. There are still some exceptions like the Ouya and Nvidia controllers where there is no SELECT button, but RetroX automap those controllers assuming that the Back button is the SELECT button. Also if you have an 8bitdo N64 controller and you use it with the N64 emulator, all buttons are automapped.

Touchscreen overlay

I also changed how touchscreen overlay works. Now there are three modes: Auto, On and Off. The Auto mode disables the touchscreen overlay only if you start a game using a controller. On and Off are self explanatory.

All devices use the touchscreen Auto mode except for well known TV devices like the Nvidia Shield and Amazon Fire devices where the default is set to Off.

Themes for RetroX

A new feature has been added to RetroX to allow using different user interfaces for the same application, this is known as Themes.

The main focus of RetroX has always been to make playing retro games the as easy as possible, just select one game and RetroX will do the best it can to run that game. How the app looked was important but second in priority, we just wanted to provide a clean look inspired of what apps like Plex and Netflix were doing at that time (2015). As time passed other emulation frontends began to do a great job on their user interfaces and given that the ease to use was well established in RetroX it was time to give some love to the way RetroX looks.

Themes is nothing new, and in fact we think that Emulation Station (ES/RetroPie) has a great themeing system, so instead of creating something completely new with all the risks involved, we made a theme engine to easily port ES themes or just create new ones from scratch.

For now, themes is not enabled by default, it is designed for TV boxes only and marked as Experimental. We’ve been testing it for a long time with many beta users but there are always some surprises when new features are exposed to all the RetroX users.

To enable Themes go to Settings -> Display -> User Interface -> TV + Themes

Theme selector

Built in themes

RetroX comes with three built in themes, one inspired in the classical clean look (RetroX Classic) and two simple themes with a light and dark mood (Plain Light, Plain Dark), but this is just the beginning, we will be adding more themes in future releases.

While in development we ported the popular Comic Book to RetroX just to test the theme engine and it looks great, that is the theme that most people have seen in our video previews of themes, but the authors of Comic Book forbid commercial distribution so we cannot include it built in RetroX, yet users can add it to their RetroX setups manually (more on that below).

RetroX Classic Theme

Background music

Together with themes we added a feature to have background music. In the past, several videos used background music when showing RetroX, and that music gave some kind of life to RetroX, now it’s a built in feature.  Of course there are options to select songs or simply shut off the music, so users are always in control.

How to add themes and music

Adding themes and music is as easy as copying files to your device, you only need to know where your “retrox.data” folder is. This is commonly located under /sdcard/ but that varies from device to device.

  • Themes: They are distributed as .zip files and must be copied to the retrox.data/themes folder. You can try with ComicBook or NES Mini unofficial ports.
  • Music: They go to the retrox.data/music folder. Currently we only support modtracker formats like .mod, .s3m and .it. There are tons of songs to choose from in modarchive.org.

As it happened with ComicBook, we used several songs by Lizardking in our demos of RetroX, but we were unable to contact him to use his music built in RetroX. If you liked those demos you can find the songs Compulsion to Obey and Desert Down here.

The future

This is just the beginning. The plans for Themes is still a long way to go, this release was done because we didn’t want you to wait any longer.

We will release a themes tutorial so other people can create themes and we plan to put the best themes available for download from RetroX, yes: online themes.

We also want to add more theme styles that will allow different kinds of navigation or game display, video snaps, automatic collections (NeoGeo, Capcom, etc).

The future looks promising!!

Pure Light theme

Current status of Amiga emulation in Oreo

The Oreo release of Android broke several emulators and most of them have been fixed up to this date, but one particular exception is the Amiga emulator (UAE2All2) which will require more time to fix, or as an alternative, be replaced by a new emulator.

Some fixes in Oreo made some hidden bugs become evident in this emulator, making it crash when opening and closing the in-game menu. These bugs were found and fixed and initially it seemed that the problem was solved, but later I found that there is a random crash that happens sometimes when you open the in-game menu.

For a long time I kept this version in hold hoping to find a solution for the random crash, meanwhile the public version of the emulator just crashed at all times. So I finally decided that a random crash is better than a certain crash, even when deep inside I know that both alternatives are bad, although I don’t want people to wait any longer.

This random crash has been tracked down, but the error happens deep inside Android where I cannot see exactly what is causing it. If you are a developer, keep reading in case you may help me fix this problem.

Normal users will receive the update, but expect random crashes.

Bug details (for developers)

The Amiga emulator is SDL based, where they have a thread to update the GL surface. When the in-game menu is opened, this thread is “paused”, the screen neither the emulator is run and the GL thread keeps waiting in a loop.

Android performs all GUI operations in one thread, the “main” thread, so before the main menu is shown, this main thread pauses the GL thread, waits until the GL wait loop is being run and then opens the main menu. Sometimes, when Android is displaying the menu it enters a deadlock.

From the scarce thread dumps that I have seen, it seems to be a problem rendering the text. Apparently, there is no other thread doing something with the GUI so in theory this lock should never fail, but it fails.

The only stack trace available of this deadlock is native:

"ora.uae4all.sdl" sysTid=29880
#00 pc 00018dbc /system/lib/libc.so 
(syscall+28)
#01 pc 000b38cd /system/lib/libart.so 
(_ZN3art17ConditionVariable16WaitHoldingLocksEPNS_6ThreadE+88)
#02 pc 00192e73 /system/lib/libart.so 
(_ZN3art2gc4Heap26IncrementDisableThreadFlipEPNS_6ThreadE+278)
#03 pc 00291367 /system/lib/libart.so 
(_ZN3art3JNI17GetStringCriticalEP7_JNIEnvP8_jstringPh+454)
#04 pc 000d8469 /system/lib/libart.so 
(_ZN3art8CheckJNI22GetStringCharsInternalEPKcP7_JNIEnvP8_jstringPhbb+544)
#05 pc 000cec6f /system/lib/libart.so 
(_ZN3art8CheckJNI17GetStringCriticalEP7_JNIEnvP8_jstringPh+22)
#06 pc 000b8275 /system/lib/libandroid_runtime.so 
(_ZN7androidL37android_os_Parcel_writeInterfaceTokenEP7_JNIEnvP7_jc
lassxP8_jstring+40)
#07 pc 00800dab /system/framework/arm/boot-framework.oat (offset 0x5c7000) 
(android.app.admin.SecurityLog.readEventsO
nWrapping [DEDUPED]+130)
#08 pc 0001422f /dev/ashmem/dalvik-jit-code-cache (deleted)

The emulator is open source and the code is located in my github, if anybody wants to take a look, just send me a message for build instructions. Thanks in advance.

https://github.com/fcatrin/rxAmigaAddOn

Live background and new YouTube channel

Retro gaming in new TV sets always have the problem of not using the full screen. Personally I don’t like to stretch the image but at the same time I don’t like to have the empty spaces / black bars at the sides.  Some emulators put an image to cover the black area but that has the problem that for some games it just doesn’t match, then I watched some videos that added a live background with the images of the game itself, with a bit of blurring and I thought that it was awesome.

So I spent some time working on the idea and I made it for RetroArch.  RetroX uses a rather old version of RetroArch (1.2.2) and I don’t know if they have done it in new versions, but at least our version will have it.  Now I will play with it a little before releasing it to the public as an option, and hopefully I will add the same to the other emulators used in RetroX.

At the same time, I announce our new RetroX exclusive YouTube channel where you can follow the development of new features and anything RetroX related. Don’t forget to subscribe to receive the updates!

Plans for RetroX v3: Theme support

Lately I’ve been thinking a lot about why other frontends are so popular while they are only “front-ends”. Don’t take me wrong, I know that they have a lot of work behind, but I honestly think that RetroX is way ahead of most Android frontends in terms of ease of use and features. Only that it seems that this is not enough.

Watching videos in YouTube I find a lot of reviews of RetroPie / Emulation Station and some reviews of other frontends for Android presented as “the best”. Sometimes I write to the authors of those videos and they have never heard of RetroX before.

I have come to the conclusion that a lot of people is attracted by visuals, and I remember the old days of Linux when a lot of people wanted to install it just to have “The 3D cube”. So their rationale is to be attracted first and then try to figure out how to make it work, and probably it doesn’t matter how hard it could be, they just want to have what they saw. (It happened a lot with Linux circa 2004). The approach of RetroX has been the oposite, give the best technology to make the process easier, but if people is not attracted first, they will never get to that point.

Personally I prefer a clean view, soft colors, smooth fonts, but that’s me! Other people clearly prefer more “joyful” views. I’ve received some comments about this from several people (Allan Mcdonald, Lee Conduit and others) but I was too focused in other priorities that I didn’t worry much about it. I should add that one of my reasons to say “no” is that I thought I would spend a lot of time finding the appropiate colors, icons, background etc. Time that I prefer to focus on new features.

But now I opened my mind about it.

I will add a new “view/layout” to RetroX to make it themeable by anyone. This will allow other people to use their own skills and tastes to create their own realization of how RetroX should look. I’ll keep the current modes and will add a new “themeable” mode. From what I’ve seen in EmulationStation with a few elements people can create really beautiful themes, so I think that this will take RetroX to new unexplored grounds.

Why not before? May be I wasn’t aware of how communities can add their own views of what is best. Yes, I’m a bit of a dictator in RetroX but this new theme system will compensate my lack of graphical skills. I can provide the foundations and anyone interested will be able to build over it, something that was brought back to my mind after opening the source code of the RetroX libraries.

The above post was published in the RetroManiaUK group on Facebook, on Aprils 1st, but it is not an April fools joke.  A few days ago I started to work on this feature, and it is looking good!

Release 2.6.6 – Sega Dreamcast

Finally Sega Dreamcast has arrived to RetroX!! This is one of the most requested system and we put it at the top of the list in our 2017 roadmap, so a lot of people were waiting for it.

I will divide this post on two aspects of this release: Users and Developers.

Users

Consider this an initial release. I left some parts to later updates because they required more days and I prefer to release as soon as I can.

The following will be added in future releases:

  • Multidisc support
  • VMU swap support
  • Settings – Full screen support
  • Settings – Region support (US, Japan, etc)
  • Settings – Performance options (frame skipping, specific fixes/optimizations)
  • BIOS boot
  • Get rid of the required clock set up

Most of these are options available in the original emulator, but not exposed in this port.

Note that this emulator doesn’t support save states, only saving progress through the original Dreamcast VMU “memory cards”. As you may expect, those saves are stored with your RetroX account in our cloud.

For developers

Honestly I was a bit reluctant to work on this system, because it is always a challenge to port a complete new emulator to RetroX. There is always a little detail that require several iterations and testing, all emulator are written different! Although this was not the exception, I didn’t think it would take the few time that it took to make the port (scattered hours among three days). Sometimes this kind of work can take at least one week.

The code base which is the Reicast emulator is very clean and fortunately most changes could be done only in the Java part. Also, the fact that this emulator doesn’t support saving states reduced the complexity of the port a lot.

This port was made in this new era of RetroX where the code is committed in public, so anyone interested can follow the track of how the changes were made. If anybody is interested in porting a new emulator, this will be an excellent example case.

The problem that took most of the time was something that didn’t happen before.  Once the options menu was displayed, the GL surface went blank.  I had to do several tests to know exactly what was the problem, and my conclusion is that for some reason, part of the GL surface was altered in a way that it was not visible anymore. Finally I came to a workaround, which is to add the view and remove it after use (not hide/gone it), this forced to GL surface to reset completely.  The code ended to be more dirty but it worked.

In comparison, the Mupen64 emulator also used a GL surface but it doesn’t have this problem. Looking at the root cause would require a lot of iterations, so I just went with the workaround.

Finally, here is the video I recorded the day before the release. Some people have asked me about the music that I was listening to – which is awesome – it is the backing track of the song Impossible Things by Nick Johnston. This guy is an incredible musician and guitar player, I totally recommend you to check his work, he have published his albums in YouTube and you can support him by buying the physical media, his transcriptions and backing tracks, which I happily did of course!

RetroX open source emulators and libs now on github

RetroX is not an emulator in itself, but a front end for existing emulators.  There are many front ends for emulators but what makes RetroX different is that the emulators have been modified to meet “the RetroX standard” like having support for custom controls, Android TV devices, RetroX save/load progress and more.

These modifications are possible because these emulators are released with open source compatible licenses, so they grant rights to modify the code and distribute the derivate products under certain conditions. One of these conditions is giving the source code back and we have been doing it since the commercial release en 2015.

But we could do it better.

Since today, the code will be available through their own repositories in github, and thanks to git subversion support the whole change history has been kept, so anyone interested will be able to see what changes we did to each emulator.

RetroX compatible emulator
RetroX compatible emulator

We didn’t make this step before due to our lack of git abilities, but since I started to use git and github everyday the move just seemed natural.  Sure we would like to do more about it, like helping integrate some fixes to the upstream projects but, we are going step by step on this as the time allows.

For such a job to be possible we should have tracked the source code as clones of the original repositories from the beginning, but as we didn’t use git until now that track is lost… Unless someone gives advice about how to create that link.  At least, the work on new emulators will have this track.

RetroX libraries are now open source

As per license requirements, all the code that is linked to the emulators has been made open source as well. So we are proud to announce that the RetroX libraries that help make an emulator to be RetroX compliant now has been released as LGPL 2.1. on github.

Want to help?

Now that this code is shared with the proper tools, we see that new opportunities arise:

  • People will be able to add their favorite emulators to RetroX (more details below)
  • People requesting fixes to existing emulators will be able to take a look and give some help directly from the source code
  • Bugs or missing features on the upstream emulators now can be extracted from our changes, with a bit of effort but doable.

Adding new emulators

We encouraged ourselves to do this step also to give other people the possibility of adding emulators that we don’t have planned to add in the near term. Some time ago we published our roadmap for 2017 and we found that it was very limiting that some people have to wait until next year to see their emulators being added to RetroX.

We will work on the emulators in that list but now other people will be able to work on emulators that are NOT in that list. Here we are thinking of emulators for machines like the BBC Micro, Amstrad CPC, FX98, X68000 and more.

Don’t worry that we haven’t gave up on those machines, only we are saying that if someone wants to do it now, they can.  If not, we will bring them in as soon as we can.

For those who want to work on that, we will give them all the required support. We already open sourced the RetroX libraries required to make a RetroX compliant emulator, but we are sure that more than that will be required.  We cannot promise nothing today but our ideal is to create a tutorial of how to modify an emulator to make it RetroX compliant. We will announce it as soon as it is available.

As a side note: From time to time people that have not used RetroX think that it is a simple wrapper for RetroArch, now you can check the changes that we have made to RetroArch to work as a RetroX compliant emulator. They are not huge but in no case they are small either.

Release 2.6.5 – Golden Eye – Better controls for N64

One of our targets has been make things as simple as possible, this included making the gamepad configurations less painful providing a centralized mechanism: Set up your controller once and for all. But sometimes underlying details makes it hard to apply one rule for all, and that’s the case of the N64 controller (read The law of leaky abstractions for background theory).

The RetroX fronted as well as emulators like RetroArch uses the SNES style controller as a basis for all systems, and a special derivate which is the PlayStation one, which simply add more buttons.  Most systems have just subsets of these two controllers, except for N64 where the controller is a completely different beast, a curious design to say the least.

To play N64 without issues you need an N64 controller, everything else will be a hit and miss.  Most emulators will request the users to map each button of their controllers but we wanted to stay away from that providing a standard configuration for SNES style controllers. As me (the developer) had almost zero experience with N64 beyond the intro of Super Mario 64, this simplification failed with other games, being Golden Eye 007 the icon if this problem.

Until now.

I changed the way that SNES style controllers are mapped adding the use of the right analog stick as “C dpad” buttons – the yellow ones in the N64 controller. Using this configuration, the directional nature of the C buttons is kept and they remain as natural as possible for the intentions of the game designer.

Given that the signals that right analog controls emit are not standard among all controllers, I added two new configuration points for the right analog control, just select them and follow the instructions so RetroX can learn about the codes used with your gamepad. You will see those new points in blue.

New analog right setup
New analog right setup

But this was not enough.

Testing Golden Eye and having some experience with modern day first person shooters, it felt more natural to invert the analog controllers, so you can strafe with the left analog and move with the right analog. Now there is a new option to invert the analog controllers from the in-game options, or make it the default for your game in the game details screen -> “configure this game” option.

GoldenEye original controls
GoldenEye original controls

And this was not enough again.

The controls still seemed awkward by design, because the strafe left/right is combined with the look up / down while modern FPS games combine strafe with move forward / backwards.  So finally I added a new option called “Optimized for Golden Eye” where not only the analog controllers work as intended, but also the trigger to shut the guns has been switched to the right (R2) and the aim is at the left (L2).

I played Golden Eye some minutes with this new configuration and it is a world of difference.

These new settings made the old Digital / Analog modes on N64 become obsolete, so now with the SELECT button you can easily switch between Original, Inverted and Golden Eye modes.

Users of 8bitdo N64 controllers

I also added an experimental setting for users of the 8bitdo N64 controllers. As they are physically N64 controllers, I added an option to automatically map that controller when used in N64 games. As I don’t have that controller (yet), this setting is disabled by default and users must enable it in the Gamepad Options.

I expect to receive good or bad feedback about this, considering it that it was done in the blind!

Also I would like to give big thanks to the members of the RetroManiaUK Facebook group for giving me these ideas to improve the way RetroX works with N64 controllers.

Also in this release…

There are also some fixes included in this release:

  • Not available games now are removed / cleaned as expected
  • Games based on CUE files now are downloaded correctly from networked storages (NAS / Cloud). These are used by CD based systems like Playstation, PC Engine CD and Sega CD.
  • Final Burn Alpha addon now is compatible with games requiring samples.  (Provided samples may be not right with some games as I found with Donkey Kong, so if you have a games with samples but no sound please send me a message)
  • Save states related options have been removed from MAME 2001, 2010 and 2014. Only 2003 supports saving states
  • Size measure of installed games coming from compressed files has been fixed.

That’s all for now and and always, just enjoy!

When will my favorite emulator be added to RetroX?

This is such a frequently received question, that we felt it deserved a dedicated response.

Regular launchers only need to send the ROM file to the emulator, nothing else. In this sense, adding emulators would be a simple enough process. However, RetroX is a truly unique “frontend”, that can do so much more.

Often front ends will just use RetroArch to support a range of platforms, but this doesn’t include those that use a keyboard, mouse or a joystick. These systems just do not work on RetroArch (Android). In fact many of the systems found within RetroX aren’t even supported by RetroArch (Amiga, MS-DOS, Atari computers, etc).

RetroX on the other hand can (and does) make desktop based games run as if they were on a console. There are still several improvements that can be made to RetroX to improve the experience for the user, but rest assured – we will. However the point I’m making is that we can!

2016-05-20 15.36.50
Save / Load states in the Cloud

Adding a new emulator to RetroX is not as easy as you may think. It’s not just a case of directing the ROM to the emulator. You also need to integrate each emulator (with all their own unique quirks) into the unique features of RetroX.

This requires us to take the original emulators source code and making the distinctive modifications required to be compatible. Be that Universal Controller Setups, Android TV compatibility or the most complicated of all, cloud based save states (and memory cards) which use the standard RetroX interface. This last point often requires additional code to be added for image processing to incorporate screenshots into our unique multi-slot save feature, all of which must be coded from scratch.

Adapting systems already within the RetroArch platform is a fairly simple process.  However, many of the emulators integrated within RetroX are standalones, all of which again require coding from scratch (including the most challenging of all – desktop based platforms).

But we love computer games!

RetroX compatible emulator
RetroX compatible emulator

As our developer resources are scarce (mostly me, Franco), we have to set priorities in the way new features and new emulators are added to RetroX. Sometimes there are small fixes or features that may only take a few hours, but others can require weeks or even months of work. Recent examples being the ability to add games from network based storages (cloud, NAS), or the code for cloud based save states which required changes to be applied and tested to each of the supported emulators.

To help improve the regularity of new features and improvements I made the decision several weeks ago, to adapt my working style to allow me to simultaneously work on both long term and short term features (who says men can’t multi-task). However, what has become apparent is that whatever approach we take, there will always be bottle necks.

So, in an effort to reduce your levels of anxiety, I can declare which emulators we want to include within RetroX in 2017, and in which order.

I hope that this will help to reduce the amount of questions that I receive (and answer) on this subject.

Here is the list:

  • Sega Dreamcast
  • 3DO
  • Commodore C64
  • Sega Saturn
  • ZX Spectrum
  • GameCube
  • Atari ST
  • Amiga CD32

In the meantime, we will continue adding new features to RetroX, with plans already in place to improve functionality in several of the existing emulators we support. Including:

And of course, non-emulator related features like offline support, or better ways to handle multiple versions of the same game etc.

As always, if you have any ideas for new features, then please contact us via our Facebook group or send us a message on Twitter.

We are always listening.