If you are reading this, it’s because you are considered a friend or part of the RetroX team. Please consider that this document is strictly private and it must not be shared. This is just for YOU.
The following is an internal roadmap for changes on RetroX that will be done in the next 4-6 months targeting RetroX 3. These changes will be worked on in parallel with those listed in the public roadmap, but these RetroX 3 ones have a higher priority.
This document is a way to write down the ideas I’ve been working on before turning them into code. It’s also a kind of set of notes for me, and a base for discussion with many of you without having to explain everything one-on-one.
Just to make it clear from the start, these are mostly changes that improve RetroX; there are no planned changes to the current pricing and subscription model.
Why these changes? I’ve always tried to make RetroX stand over other Android emulation frontends with its ease of use and (still) unique features. Many people have acknowledged that and have given their support throughout all these years, but new apps and hardware are always adding more offerings to the RetroX target users, and I want to keep RetroX ahead of all possible competitors. I’m taking into account that some of them already have a strong user base on other systems, like Launchbox, and others have the potential of bringing exciting ingredients to the mix, like Polymega. Not to mention the plethora of “mini” retro consoles appearing all the time.
Given this scenario, it’s not just a matter of adding new emulators. Currently, RetroX supports 27 systems, and adding one more is typically something that doesn’t produce much change for most users. I’m not saying that I won’t be adding more, but I don’t see it as a priority now as I saw it in the past. Currently those efforts are better used to fix or update currently used emulators like N64, PSP, and Dreamcast.
Now, let’s go for the plan, so bring your slightly larger glasses!
User Profiles
RetroX is designed to be used by only one person, but given that many people are using RetroX in a shared TV setup or they share their account with their family devices, I see a need for Netflix-style profile users. By default, the app will use one hidden profile just like it is now, but you will be able to create more profiles for users to select at launch, so each one can save their own favorites, cloud saves, and other info that may be associated with the user account. This will allow for a more interesting feature: Child profiles.
Child profiles
There is no doubt that children enjoy retro games, but for obvious reasons they don’t have the judgment to look for games if they have to select a system first. Also, some still don’t know how to read/write to find a game, and they shouldn’t be exposed to violent or inappropriate content given their age.
A Child profile will switch to a simplified user interface designed for children, and the account owners will have the tools to filter the content so their children only find the games that are considered appropriate for them.
Better aspect ratio options
Currently, there are two aspect ratio options: stretch to fill the screen and “original”. Original seemed like a good thing because it uses a 1:1 pixel aspect ratio, but many systems didn’t have square pixels and they are displayed incorrectly with that mode. For example, NES games currently look narrower than the expected 4:3 aspect ratio, and other games, like Street Fighter II in some MAME versions, look wider than that same 4:3 aspect ratio.
The Analogue mini consoles provide interesting aspect ratio modes to fit the user preferences better. Some of those aspect ratio options are currently implemented in some emulators, but not being used by RetroX. The target will be to bring those aspect ratio options to RetroX to allow real 4:3 mode and integral scaling to avoid artifacts.
Now, adding these options will bring complexity, but RetroX will use the best defaults for each system.
To better understand the issue and the opportunities with aspect ratio options, here is a video (options start at 8:20).
More background options
Right now, RetroX offers black or live backgrounds. Live backgrounds use the current frame data to paint a blurred image using that frame as the background. It gives a sense of full-screeness, but it requires more resources and may seem annoying to many people, which is why it’s turned off by default.
Live backgrounds will be improved by adding a border around the game image, but two additional background options will be added:
- Static images: The user will be able to select a static image to be used as a background among a set of images provided by RetroX. Those images will be included with the app and/or will be hosted online like it is already being done with themes. Also, the user will be able to throw their own background images under retrox.data/backgrounds. This method can be seen in consoles like the new Sega Genesis Mini, and it looks really great.
- Bezels project: The Bezels project is a big database of backgrounds and artwork for specific games. As it is being done with the cheats database today, RetroX will allow the user to enable the Bezels project to bring the artwork automatically with minimum or no configuration by the user.
UPDATE: Improved live borders and static images were released as v2.9.2.
UPDATE: Bezels project was released as v2.9.24.
EmuMovies integration
RetroX downloads the artwork for each game automatically, but now that video snapshots have been added, it requires more work from users to have “the full experience” in their setups.
I’ve been talking to the EmuMovies people so they can give me access to sync users’ content with their artwork database, like many other frontends currently do. Once done, EmuMovies users will be able to bring their artwork directly into their devices automatically.
UPDATE: This was released as v2.8.2.
Automatic gamepad mappings
When RetroX started, there were no standard gamepad buttons for Android, and the user needed to teach RetroX how their controller buttons worked. Not anymore. In recent years the controller buttons have been standardized a lot, so now it is safer to assume a certain button layout.
RetroX will assume that the gamepad that starts the game is Gamepad 1, and if an event from a new gamepad is received, it will be considered to be Gamepad 2, then 3, etc. It is something that RetroArch currently does, only that, because of the Android controller chaos of the past, it would have been very risky for RetroX to do it that way.
The user will still be able to map the buttons, but that will be optional. Also, the mapping will be associated with the gamepad brand/model and not the plugged gamepad like it is now.
All mapping info will be stored with the user account, so once a gamepad is mapped, there will not be any need to map it again. Never.
UPDATE: This was released as v2.9.0.
Theme Styles
Currently, Themes mode supports only Emulation Station-style themes, but that’s only the beginning. New theme styles will be added to support other interesting types of layouts and user experience. Of course, this will be used for enabling features such as child profiles.
What exactly is a theme style? It defines behavior and graphics elements. For example, an ES-style theme has two screens: a system selector screen and a game selector screen, and each of those has different graphics elements or widgets like lists, texts, shots, etc. A new theme style may bring a new game selector like a coverflow type of selector or a card selector like the one used in TV mode, etc. Also, a new theme style may have no system selector at the front (for children), a separate search screen, and more.
Hopefully, although not mandatory, legacy user interface modes like TV and Mobile will be turned into Theme styles, so a big chunk of code might be removed, making the codebase easier to maintain.
Just as a tease, look at these possible theme styles:
Add support for standalone emulators
Some systems have better emulation using closed-source emulators that cannot be integrated with RetroX (3DO, Jaguar, Dreamcast). Some people want to use these emulators but still manage their game collections inside RetroX, so they will be able to launch a game using those emulators.
This feature will be tagged as “not supported emulator”, and users will need to set them up themselves.
Although it may work poorly because of the lack of integration, this is the only experience that other frontend users have been used to.
Better content sources
Currently, users can add content just by copying the files to their devices or adding SD cards/USB drives. They can also add games using cloud storage services and local networks through NAS or Windows computers. Cloud storage has speed and size restrictions, and NAS has always been troublesome because of the protocols involved, even when some people have managed to make it work for them.
That will be improved through two methods:
- The user will be able to install a small program (RetroX Server) on their computer to share a folder with their Android devices. Just pick the folder, and your Android devices connected to the same local network will be able to add games from that folder, either on demand (once the user selects the game) or by transferring all the games to the device, so they can sync once and then disconnect from that network.
- Private cloud services will be added: OwnCloud, NextCloud, and Tonido.
New emulation system that replaces RetroArch
Currently, RetroX uses several emulators, but RetroArch is the one that supports most systems and it is wildly evolving. Now, that could be a good thing, but at the same time that is a bad thing. RetroArch is becoming bigger and bigger, and not only does it have to support a wide variety of host systems (PSP, PS3, washing machines, toasters…), but it also sometimes adds corner features that lie outside the scope of the common RetroX user, just adding complexity to the codebase. Having said that, the main problem is that depending on third parties is always a risk, and it is time to make a jump.
RetroArch is not an emulator in itself; rather, it is something like a shell for emulators that implements the open libretro specification (made by themselves), so in theory those emulators can run under a different shell with different design goals… like RetroX. For example, RetroArch has two user interfaces (legacy and Lakka), and neither is designed to be easy to use, but rather to be powerful (even I struggle trying to use it!). Also, needed features like having an Android-TV-compatible keyboard seem to be quite low on their priority list compared with other, more in-demand features like… adding text-to-speech.
So I’ll be creating a RetroX shell for libretro for better overall integration. For example, today I feel that the in-game menu in RetroX + RetroArch is like having another app opened instead of something that is running inside RetroArch, and features like instant shader or aspect-ratio switching would be almost impossible to do with the current approach.
Having that shell for RetroX will allow me to port computer-based emulators to libretro together with the Android TV keymapping, so I will be able to drop those old SDL-based emulators that have been having problems on every Android update like DOS, Atari800, and Amiga, replacing them with libretro-based ones.
Also, having that libretro shell will make it A LOT easier to bring the next change…
RetroX for Computers
Yes! The time has arrived: RetroX will be ported to computer-based systems: Linux, Mac, and Windows, in that order. Why Windows last? Because they already have Launchbox!
After the codebase was reworked to implement Themes, RetroX gained some distance from Android, and a second iteration on that separation, together with the RetroX shell for libretro, will allow us to bring RetroX to computer-based systems.
This is like what Launchbox is doing, but the opposite: bringing their PC app to Android, with an additional twist: Having RetroX for Linux will open the doors to using a lot of interesting and powerful single-board computers that have been appearing in the market, like the Raspberry Pi, Atomic Pi, and LattePanda. Just watch the ETA Prime and Explaining Computers channels to see the amazing devices RetroX will be running on. I personally have preserved my RetroFlag cases for this moment.
I know, RetroX today runs on Raspberry Pi using Frambu, but it’s still Android-based, and even for me, Android over the Pi seems to take ages to boot.
No additional licenses or fees will be required to run RetroX on these devices. A standard RetroX subscription will allow any user to run RetroX on their preferred device, whether Android- or Linux/Mac/Windows-based.
Other smaller but needed changes
- Easier login. Users who can’t use their Google accounts to log in will be able to log in just by giving their email addresses, so they can authorize their devices just by clicking a link in their email.
- Easier account activation. Similar to the above, users will be able to activate their accounts without using Activation Codes.
- Shaders will be allowed to be changed with the game running. Also, they will be able to be set as global, per system, or per game.
- Palettes: Switch palettes for certain systems like NES. Currently, Game Boy supports palettes in RetroX.
- Emulator changes or updates for better performance/compatibility: N64, PSP, Dreamcast.