Blog – Page 50 – Libretro

In the run-up to RetroArch 1.1 – what’s ‘new’ pt. 2

December 12, 2014December 23, 2015 Libretro Team

We’ve been away for half a year so there is a lot to talk about in this new upcoming release. Rest assured I’m working hard as hell to meet the Christmas sweet spot. It will take a couple of blog posts to go through it all. So let’s start with the first one. I’m putting these articles out now because I really don’t fancy having to write all this stuff later on in the holidays when I drop this stuff.

In this blog post, let’s talk about some other new cores you can expect.

Continue reading “In the run-up to RetroArch 1.1 – what’s ‘new’ pt. 2” →

In the run-up to RetroArch 1.1 – what’s ‘new’ pt. 1

December 12, 2014October 18, 2015 Libretro Team

In this blog post, let’s talk about one of the big new cores you can expect – gpSP.

gpSP

There has been some complaints in the past that the Game Boy Advance libretro cores are a bit too slow on some older systems. So people with lower-performance devices should probably be glad by the arrival of this core.

This is a Game Boy Advance emulator written by Exophase originally for the PSP. It was a fast and reasonably compatible GBA emulator that later on made an appearance on platforms like iOS and Android by unofficial porters.

Exophase stopped working on this emulator around 2009 and ever since then the codebase has been gradually decaying. The interpreter CPU core was broken on 64-bit CPUs, the x86 dynarec was 32-bit only, and there is just no central repository that aimed at making this a reasonable first-class citizen that could compete against things like VBA-M and bgba.

So the libretro core is an attempt to do all that. It uses as a base notaz’ gpsp repo but strips out the Pandora/Raspberry Pi/GP2x-specific code and aims for a more general-purpose codebase. We managed to get the ARM dynarec working on Android with some code edits, and we also fixed a few bugs that was preventing the interpreter core from working on Intel 64bit architecture.

Performance-wise, the main substantial difference is when the dynarec is enabled obviously. This core should be substantially faster right now on ARM 32bit systems (Android/iOS/Blackberry, etc) than VBA-M and the VBA-Next cores ever did. It should be fast enough on Raspberry Pi and low-end Android devices like the Xperia Play. The 32-bit x86 dynarec should also be very beneficial for users that don’t mind putting up with 32bit code. Getting a 64-bit dynarec up and running is something that is on the installment plan (for me anyway).

Savestates should work but don’t expect to be able to use savestates from other gpSP-based emulators like Gameboid or whatever. We had to change the savestate format/size during our 64bit compatibility patches, so this is unavoidable. Though really you shouldn’t expect savestates made with non-libretro based cores to be compatible with libretro cores necessarily anyway, so let’s not pretend like this is an issue.

As for how the performance is like with the interpreter? It varies from game to game. Games like Tekken Advance and Super Mario Advance are actually slower with the interpreter core than the same games on VBA Next, but then you have the odd exceptions like Metroid, Zelda, Wario Land, Donkey Kong Country games and Astro Boy where the performance with interpreter gpSP is at least twice as fast as VBA Next. Hopefully in the long run we can fix these remaining bottlenecks with interpreter core so that there is a nice counterweight to VBA-based emulators that is at least substantially faster even with just the interpreter core.

So what’s done?

– Runs on Android with the dynarec.

– Runs on 32-bit Intel with the dynarec.

– 64bit compatibility patches so that interpreter core runs on 64bit CPUs.

– Savestates work, SRAM works, most general features you’d expect from libretro, etc.

What still needs to be done in the future?

– Get the ARM dynarec working on iOS which requires some more patches. For now, the iOS port is using the interpreter so performance is not yet as great as it should be.

– Find some way to drop support in for Normatt’s open-source BIOS replacement so that users don’t necessarily have to use the ‘official’ GBA BIOS.

– Make the performance with the interpreter core a lot more even across games. Some games getting easily twice the performance as VBA Next while some games are actually 100fps lower than VBA Next seems to indicate that there is room for improvement here.

– Do the same as what I did with VBA Next/VBA-M cores and just ‘bake in’ the needed ‘assets’ that this emulator needs. Right now it needs a file called ‘game_config.txt’ present in the system directory which enables some idle loop optimization speedhacks among other things. This should all just be baked into the core later on.

– Make it big-endian compatible so it can run on consoles and PowerPC-based Macs.

– (If I have time to waste) write a PPC dynarec so we can really have a fast GBA core on PowerPC-based targets.

Hyperkins’ Retron5 – continuing licensing problems

September 24, 2014October 18, 2015 Libretro Team

Yesterday, Hyperkin responded to our earlier article by acknowledging that they indeed did do what we claimed them of having done. In response, they posted a raw source code dump of the video game emulator software in question, confirming they were indeed infringing copyright and violating licenses.

http://www.nintendolife.com/news/2014/09/hyperkin_responds_to_accusations_of_infringing_on_the_rights_of_emulator_creators

http://retron5.in/node/9

However, they did not open source the code taken from the RetroArch project that is used within Hyperkin’s own frontend software.

By using RetroArch’s GPLv3 code, they are not only violating the license but breaking clauses that prohibit “Tivoization”

Today, Hyperkin posted another statement regarding the allegations of RetroArch code, admitting that code is indeed used in their product shipped in all versions of their firmware below the most recent release.

https://www.retro5.net/viewtopic.php?f=11&t=57&sid=638613d1c1de4fc414c15cc2654597e1&start=10#p267

I’d like to clarify one point regarding the allegations over at libretro.com: we are not using any of RetroArch in our “frontend” (libretron.so). While it is true that a few ASM functions from RetroArch were previously found in our frontend library, these were merely remnants of old test code which we unfortunately forgot to remove. The offending code has been removed as of the v2.0 update. We’re sorry that this code was left in the binary up until recently; it was merely an oversight on our part. Furthermore as you will see from the source release of the emulator cores, we have our own interface between the frontend and the core plugins, totally different from that used by RetroArch itself.

As our frontend does not include any code from the RetroArch frontend then it does not fall under GPLv3 as they claim, and thus is not bound by any of the anti “TIVO-ization” stuff.

We believe that previously distributed copies of Hyperkin’s firmware now fall under GPLv3 licensing and anti-tivoization terms and must be open sourced in order to adhere to the license. Also, we do not know the legality of selling a product with a firmware containing GPLv3 code in a TIVOized state, and then removing that GPLv3 code later on in a successive firmware update to effectively TIVO-ize it. That is something for FSF lawyers to ponder.

Visual evidence of RetroArch’s code in use by Hyperkin’s frontend binaries can be found here:
– http://imgur.com/a/i56YF
– http://www.libretro.com/index.php/retroarch-license-violations/ (see middle section titled “RetroArch”)

This can be compared against this codebase snapshot (they based the code’s inclusion on this snapshot of the code) –

https://github.com/libretro/RetroArch/tree/2be201ecf39077c864d06089a5b48aa97b170f8d

They’ve also alluded to using forced firmware updates to make sure the user cannot run original copies of the GPL software they bundle on this device, further adding to the TIVoization claims –

http://www.gamnesia.com/articles/gamnesias-exclusive-scoop-on-the-upcoming-retron-5#.VCKBh-IvBhE

Q: Assuming someone does break into it, how are you going to deal with that?
A: We do provide firmware updates through SD card support. If we start noticing people hacking and things like that—which I’m not against whatsoever; that’s the times we live in now, where if you could hack something, you’re a genius—we can release firmwares at any moment that would be required to start playing games. With that, you know, we can limit the control on that. – See more at: http://www.gamnesia.com/articles/gam…5#.VCKBh-IvBhE

There is another problem with what was stated here –

https://www.retro5.net/viewtopic.php?f=11&t=57&sid=638613d1c1de4fc414c15cc2654597e1&start=10#p267

They claim they no longer have any RetroArch code in their latest firmware and that they have their own API that they use to dynamically link the core against their frontend (unreleased and closed-source). The problem with this is that their API appears to be not GPL-compatible.

For evidence, download the ZIP contained in here (RetronN5Source-20140923.zip) and look at engine/retronCommon.h.

http://retron5.in/node/9

This API would need to be under a GPL-compatible license to be compatible with FCEU and VBA. Furthermore, it’s unknown what license the ‘frontend’ is licensed under, and since it’s closed-source and kept concealed, there’s no way of knowing if it infringes on the GPL license or not.

A core being exposed to the frontend through an API like this constitutes a combined work, because it is not a ‘well-separated work’ as per the terms stated here –

http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem

The core doesn’t do anything without the frontend, and the frontend links to this core dynamically through dynamic linking. The core is reliant on the frontend to do the audio/video/input processing, without which nothing would be displayed on the screen, no input would be received by the core, and no audio samples would get output.

Therefore, we believe that their latest acknowledgements raises even more questions as to the level of compliance they’ve demonstrated so far with the GPL license. It raises therefore even more questions than it solves, further adding to the already quite considerable list of problems with this device.

Non-commercial cores – SNES9x Next

And of course, the fact that the two non-commercial cores are still being shipped with the device is another problem altogether. The license for SNES9x states specifically:

https://github.com/snes9xgit/snes9x/blob/master/docs/snes9x-license.txt

Permission to use, copy, modify and/or distribute Snes9x in both binary

and source form, for non-commercial purposes, is hereby granted without

fee, providing that this license information and copyright notice appear

with all copies and any derived work.

This software is provided ‘as-is’, without any express or implied

warranty. In no event shall the authors be held liable for any damages

arising from the use of this software or it’s derivatives.

Snes9x is freeware for PERSONAL USE only. Commercial users should

seek permission of the copyright holders first. Commercial use includes,

but is not limited to, charging money for Snes9x or software derived from

Snes9x, including Snes9x or derivatives in commercial game bundles, and/or

using Snes9x as a promotion for your commercial product.

The copyright holders request that bug fixes and improvements to the code

should be forwarded to them so everyone can benefit from the modifications

in future versions.

Super NES and Super Nintendo Entertainment System are trademarks of

Nintendo Co., Limited and its subsidiary companies.

“Commercial users should seek permission of the copyright holders first” – refer to Hyperkin’s Retron5 licensing software page here –

http://retron5.in/node/9

They used the SNES9x Next fork specifically. This is a fork that I created specifically to serve as a libretro core. My list of contributions extends to the following:

– Added game-specific speedhacks to make them fullspeed for low-power systems like the Nintendo Wii and PlayStation3. This includes games like Final Fantasy III/VI, Star Fox, Star Fox 2, Super Mario World 2: Yoshi’s Island, and numerous other cores which were previously too slow on such devices.

– Added SuperFX overclocking code to make it possible to run SuperFX games at faster rates.

– Converted the entire codebase from C++ to C89.

– Wrote the libretro API integration parts together with Themaister/Hans-Kristian Arntzen. (NOTE: Libretro is licensed under the MIT license)

As you can guess, they have never sought my permission to use this in their commercial product. And they will never get it either. They are expressly forbidden by me (one of the copyright holders) to use this version of SNES9x in their commercial product. I’m still awaiting a response from the rest of the upstream SNES9x devs but I can’t expect their reaction will be that much different.

I will be taking steps of my own accord to ensure that this situation will be rectified.

Non-commercial cores – Genesis Plus GX

The Genesis Plus GX developers have been made aware of the facts as well and they can make their own moves as to how to deal with this.

On SNES9x Next however, I have considerable copyright claims and therefore I am in an ideal position to clamp down on this misuse of its code.

Last parting message

This can be read from Hyperkins’ response to our earlier article on Nintendolife.com –

It has always been our intention to release the relevant source code for the open source emulators used within RetroN 5. We have not been as quick as we could have been, since we have been busy improving the RetroN 5 user experience. The relevant source code has now been released. From this point forward we will not only keep our copy of this code updated for those who wish to obtain the latest version, but also submit patches for any fixes that we implement back to the original projects so that the entire community may benefit. Hyperkin will continue to endeavor to fulfill the licenses of any project used within RetroN 5 and any other software we write.

If Hyperkin is indeed serious about this, they will save my time and the time of the Genesis Plus GX developers by pre-emptively (and immediately) stripping the non-commercially licensed SNES and Genesis cores from their product. We’d rather be busy doing actual development that users benefit from and that benefits the community instead of having to go to the trouble of sending a bunch of Cease & Desist notices.

Also, let it be known that as of this moment I have contacted the FSF regarding the GPL violation matters because there remains too many unanswered and unsolved problems for us to be thoroughly satisfied. Our beef is not with the product – if Hyperkins’ Retron5 was put out in a honest way and in a way that wouldn’t infringe upon the licenses of these emulators, they would be legally allowed to use it in this way. As it stands, they did not do their homework before putting this product out and their actions so far reek of negligence, irresponsibility and a calculated move to reap the rewards of copyleft code without having to honor the license’s terms.

RetroArch, Libretro core license violations by Hyperkin’s Retron5

September 19, 2014October 18, 2015 thetoadking

We have an open-source project called RetroArch. It has a development interface called libretro that allows for the easy creation of emulators and games that can plug straight into this program called RetroArch. This development interface is open to others so that they can run these pluggable emulator and game cores also in their own programs or devices. You can find this project on Github. (github.com/libretro). We also have a website – http://www.libretro.com. We started this project in late 2010 and we have been steadily increasing in popularity. We are on over 15 different hardware platforms right now that you can run RetroArch on, including Android (which this Retron5 device is based on).

These open-source programs are covered under certain licenses. Several of the emulators are covered under non-commercial licenses, which means they cannot be sold or profited from.

We have discovered that Retron5 is in violation of the licenses of several projects:

Genesis Plus GX
1. It uses the open-source emulator ‘Genesis Plus GX’ by author Eke-Eke for its Sega Genesis/Mega Drive module (https://github.com/ekeeke/Genesis-Plus-GX). This core has been licensed under a non-commercial license. It can therefore not be sold as, or part of, a commercial product.

Proof is in the accompanied screenshots at the bottom of this post. None of the authors were contacted about their code’s use in the Retron5 hardware.

More evidence: (1, 2, 3, 4, 5, 6)

SNES9x Next

2. It uses the open-source emulator ‘SNES9x Next’, which is itself a derivative of SNES9x (https://github.com/libretro/snes9x-next). I (Squarepusher) personally made this version of SNES9x. It has a few differences compared to normal SNES9x. It has SuperFX overclocking code and it has certain game speed hacks that make games run faster on slower hardware. This comes at the expense of some graphics inaccuracies though.

We could tell it was the SNES9x Next core because the exact same strings for variables to do with the speed hacks and the SuperFX overclock code popped up in their SNES core.

SNES9x is licensed under a non-commercial license. Like Genesis Plus GX, it can therefore not be a part of a commercial product.

What also bears pointing out is that SNES9x Next has never been released in any other version than the libretro version. Libretro is the development interface of RetroArch if you remember. We will return to this later on.

Proof is in the accompanied screenshots (see below). None of the authors were contacted.

More evidence (1, 2, 3, 4, 5, 6).

FCEUmm

3. It uses the open-source emulator ‘FCEUmm’ for its NES module, which is itself a derivative of FCE Ultra. FCEUmm is licensed under the GPLv2. Technically they would have been allowed to sell this IF they had made sure their frontend was compatible with GPLv2. Unfortunately, this turns out not to be the case as we’ll find later on – since they are using GPLv3 code inside their frontend as well which is technically incompatible with this license.

Proof of it being FCEUmm is in the accompanied screenshots (see below).

More evidence (1, 2, 3, 4, 5, 6)

VBA Next

4. It uses the open-source emulator ‘VBA Next’ for its GBA module. VBA Next is a derivative of another emulator called VBA-M. I (Squarepusher) made this version specifically and I could recognize it was this version because of the fact that I have built-in a game database into this emulator. The game ID strings that are used to identify the ROMs appeared in Retron’s GBA module as well. As for the rest of the code, it is undoubtedly VBA. The screenshots showing the code flow of operation will illustrate this clearest.

VBA Next is licensed under the GPLv2. None of the authors were contacted. Proof is in the accompanied screenshots (see below).

More evidence (1, 2, 3, 4, 5, 6)

RetroArch

5. We found obvious bits of RetroArch’s sourcecode inside their frontend. Now the reason we could identify these snippets is because it is inlined Assembly code that is hard to obfuscate. The relevant parts are the ARM NEON-optimized sinc resampler code and the audio integer to float conversion routines. If you want photographic evidence, I refer you to the second link I posted below.

All of the other C code of RetroArch seems to have been obfuscated so it will take us some more time to identify these parts. What is evidently clear though is that they are already in violation of the GPL license that we covered this RetroArch code under. GPL version 3 specifically forbids TIVO-ization. Let me explain later what TIVO-ization is. It basically means that you use opensource software to make a locked-down hardware device that doesn’t allow you the freedoms that the GPL generally provides to users and developers alike.

Since they have used our libretro cores evidently and since the only way to actually use these cores is through a libretro frontend implementation, and since actual RetroArch code has already been identified in their frontend, this raises serious questions as to how much of their frontend constitutes ‘original work’ and how much of it is just RetroArch. Either way, they are in the wrong for several reasons here:

– They should have also made these publicly available for every user to download since that is part of the rules and stipulations of using GPL code.
– They made a locked-down crippled hardware device based on open-source software. You void your warranty if you attempt to modify the copyleft-licensed software on this product and furthermore it doesn’t even allow you to do this. It is not possible to run the original, non-crippled RetroArch frontend on this device, only the crippled one provided by HyperKin. It also uses encryption as a means to obfuscate and hide the originating source of this software. This is TIVO-ization and the GPL version 3 was specifically made to prevent this.

What is TIVO-ization?

http://en.wikipedia.org/wiki/Tivoization

Tivoization /ˈtiːvoʊɨˌzeɪʃən/ is the creation of a system that incorporates software under the terms of a copyleft software license (like the GPL), but uses hardware restrictions to prevent users from running modified versions of the software on that hardware. Richard Stallman coined the term in reference to TiVo’s use of GNU GPL licensed software on the TiVo brand digital video recorders (DVR), which actively blocks users from running modified software on its hardware by design.[1][2] Stallman believes this practice denies users some of the freedom that the GNU General Public License (GNU GPL) was designed to protect.[3]

The GPL version 3 was specifically made because GPL version 2 did not provide enough safeguards against abuse like in the case of the TIVo digital video recorders. They would take from open source, not credit anybody and not give anything back either – and even create a closed platform around it where they would set themselves up as owners of the software (and in effect the hardware).

GPLv3 forbids you from building a gated community around open-source software like this and giving nothing back in return. The fact that they have used RetroArch’s GPL version 3-licensed audio resampler code in a product that is running a locked-down, encryption-crippled version of Android is already bad enough. That they don’t even provide to users the ability to run content on this device without any restrictions is another serious concern.

Anyway, as it stands right now in its current state the product is using parts of our software illegally. There were also some other things found that were legally questionable like a Microsoft-licensed Verdana font which is covered by a End-User License Agreement, so there are multiple license violations here at play.

More evidence of RetroArch appropriation (1, 2, 3, 4, 5, 6, 7).

Multiple license violations, multiple conflicting licenses, bad faith

The problems with this are many-fold, but for us it comes down to mixing non-commercial cores on this device with more permissively licensed cores, the infringement of the emulator authors’ rights, the lack of credit paid where credit is due, the lack of freedom in the hardware device (which restricts the user in what he/she can do and makes him/her reliant on Hyperkin to serve as the gateway keeper since he/she can’t uncripple this version of Android on their device without voiding their warranty and they can’t run the uncrippled RetroArch frontend on it either), and the multiple conflicting licenses. Also, the fact that changes / patches to the sourcecode have not been provided to customers of this device. These should have been made available on a public place free of charge.

Open-source is not a matter of doing with it as you please. The license is there for a reason and it needs to be followed, and it dictates how you should go about your business when deciding to make a commercial product out of such software. GPL is known as a ‘viral license’ which means that the community behind this uses the viral nature of the GPL as an effective strategy to ensure more and more software gets licensed under the GPL, since every bit of GPL code that gets incorporated into another project needs to be made GPL or GPL-compatible as well otherwise it’s a violation of the license. As it stands right now, the software for the Retron5 is very likely illegal to distribute.

Links:

1. http://imgur.com/a/T6W4e – This image gallery shows comparisons of the infringing derivative Retron code vs. the originals

2. https://www.anonimg.com/img/5d807718b069e5dae8a4e4320fdda1ab.png – This shows the RetroArch audio resampling and audio conversion routines in the Retron frontend

3. http://i.imgur.com/81bnckH.png – Another image of the audio resampling code. Originally from this tweet: https://twitter.com/FioraAeterna/status/512790355591196673

4. Regarding the MS Verdana font: http://www.microsoft.com/typography/fonts/font.aspx?FMID=1817 – “Verdana is either a registered trademark or a trademark of Microsoft Corporation in the United States and/or other countries.”

(EDIT: A section here about the ARM Mali drivers was removed since it appears to not be related to these issues)

(EDIT2 [9/20/2014]: Updated with more pics of evidence)

After RetroArch v1.1 – RetroBox

August 9, 2014October 18, 2015 Libretro Team

I was meaning to make this announcement after RetroArch v1.1 was released and this idea has been a bit long in the works. However, due to some sudden unexpected Kickstarters that have taken similar concepts and tried to create some kind of questionable monetization scheme around it, I felt compelled to make a pre-announcement about what we’re going to do post-RetroArch v1.1

RetroBox and why it’s needed

So the concept of RetroBox is based on a couple of problems:

There’s no real game console that is ‘open’ and which allows RetroArch to be on there without a jailbreak or a hack of some kind.
The ‘consoles’ that are open have an OS (Android) that is absolutely unsuitable for real-time performance oriented apps, such as (I don’t know) games. I’ve talked about this incessantly since 2012, but finally even the commercial games press seems to be becoming aware that there are definite performance bottlenecks associated to Android that prevents games from running at a stable deterministic framerate (read about all the problems here for instance – hardware that should be more than powerful enough with any other OS that do the job properly – http://www.eurogamer.net/articles/digitalfoundry-2014-nvidia-shield-tablet-review)
SteamBox/SteamOS seemed like the perfect vehicle at first for a true ‘open source’ gaming console that gives us a little bit more freedom than the typical Sony/Nintendo/Microsoft offerings. However, plenty of problems there as well. First of all, the fact that it’s limited to Intel. Second, the high prices these SteamBoxes are going for. Third, the unconventional gamepad which seems just totally ill-suited for the kind of ‘retro games’ that are commonly played in RetroArch. Fourth, the fact that it’s still by a commercial company like Valve, which operates its own DRM app store, and therefore at any time (no matter how well-intentioned) can change what is allowed and what isn’t on the platform to suit its business model. Fifth, SteamOS is a bit less ambitious than I initially thought it would. Still being dependent on X11 means we still don’t escape the X11 performance tax when ideally they should have just made their Steam launcher run on top of DRM/KMS inside a console for optimal latency. A bloated Debian distribution might make for a ‘safe’ OS but not sure if Debian is the right way to go for a gaming OS and it’s going to cause a lot of maintenance issues in the future.
All of these ‘alternatives’ that exist so far, either fall into the Android camp and are therefore no good (Ouya and the usual suspects), and/or they are being run by entrepreneurs who put their bottom line first before any passion for the project in general. Trying to base your operations around such a thing is like trading one evil (the big silo’ed off console platform holders) for another one, and in the end I’m not sure if the newer evil is going to be all that better to begin with.

RetroBox

So what is the RetroBox project going to amount to?

Figure out a way to turn ARM/x86 small form factor boxes (from Intel NUCs all the way into XBMC boxes) into plug-and-play game consoles powered by RetroArch.
Have a free open source distribution that is very lightweight.
Strive for the most optimal conditions possible – ie. DRM/KMS mode, no X11, minimal packages installed in this distro other than what libretro ports/RA actually needs.
Make this a ‘Proof of Concept’ for what a game console centred around the libretro API can be.
Plug-and-play – can be operated with a gamepad entirely, keyboard and mouse are entirely optional.

RetroBox will be an open-spec game console. It’s not owned by any particular company, and it will operate much like the 3DO/VCR model where any manufacturer could make his own box. Because RetroArch is so impressively multi-platform and portable, you don’t even have to limit yourself to a specific processor architecture like ARM – most libretro ports are available for most microarchitectures available, so you can pick and choose your own hardware.

The aim here is to create an ecosystem that is more open, more optimal and definitely more interesting than what is provided so far by the Androids, iOSes, and Steams of this world. And to have a POC game console platform of our own that illustrates this best.

Why is RetroArch a good fit for this?

From its inception, RetroArch has featured a gamepad-controlled UI that has thrown many PC users for a loop that were used to traditional WIMP point-and-click UIs. We have sticked to our guns for a long time and maintained this was the right road to travel, because we always envisioned RetroArch as this ‘game console platform’ all unto itself. RetroBox will see that high-level concept come into reality and made even more convenient.
Our API perfectly allows for the kind of plug-and-play portability we want and need through this game controller abstraction called the RetroPad.
RetroArch is second to none when it comes to optimal audio/video. Despite the so-far pretty lacklustre eyecandy found in its UI, there is basically nothing out there it plays second fiddle to when it comes to this department. And it’s also one of the few projects that aims for certain best practices on Linux like ensuring that everything can be ran from DRM/KMS instead of just solely depending on X11. Latency, audio/video performance, and the impeccable shader subsystem all make for a great platform for a game console.
People are already doing this right now anyway. There’s an obvious demand for this and there’s an obvious need among all those ARM boxes to introduce some sanity to them and to make sure that things run right out of the box. It’s a lot of work having to fiddle around with these boxes and to even get semi decent/passable performance out of them. Might as well focus on this and make it part of the overall plan

So what is this project NOT going to be?

Every effort will be undertaken to ensure this will not be your typical sleaze-ridden entrepreneurial ‘scam’ where the main incentive is ‘get-rich-quick’. There will be NO Kickstarters, no Indiegogos, no crap like that going on. I would find it morally unconscionable raking in thousands of bucks for an undertaking like this off something that is typically going to be used by most people as a way to play emulated videogames run on copyrighted trademarked video game consoles made by commercial companies. If other people want to sell out and try to make themselves a buck off this ‘retro game stuff’, they can go ahead and do it. We will try to maintain a clean nose and keep ourselves out of this potential legal quagmire. The ramifications will be huge in the long run and we refuse to have any part in it.

So, crowdfunding is not an option. So far we are going to run the RetroBox project with our own personal finances and with the hardware we already have. Which is why it’s essential that we have your support in this endeavor. Hardware gifts will be of the utmost importance in ensuring this project will become better. However, hardware gifts will only be necessary for stuff we necessarily need – so that this doesn’t become another way of profiteering altogether.

Not just about emulation

Also, RetroBox will NOT be only about emulation. I keep stressing that RetroArch is NOT a multi-system emulator frontend, and I mean it. I want to ultimately see this evolve into its own game platform, with indie games, emulators, games, virtual reality applications and rich multimedia applications all competing for the user’s same attention. So you will be also seeing a lot of additional stuff not related to emulators at all, but which will be just as exciting.

Of course, because this is an open-spec console, emulators don’t get relegated to the sidelines like they would on a traditional videogame console. This is what will make RetroBox different – the freedom is in the hands of the user, and the platform holder doesn’t dictate to the user what he/she can’t do with this box.

What about features that people want to see?

We will try to make sure that this has as many of the bells and whistles that these sleaze-ridden KIckstarter-founded projects have such as Ignition and Gamertopia. The whole NES Remix-idea for a kind of retro game console is a good idea, as is netplay, leaderboards and that kind of thing. We think we can do all of this better anyway because of RetroArch’s impeccable cross-platform nature. I think we can do this netplay in a way that every RetroArch port out so far on any platform can play together with the RetroBoxes all the same.

What about standardization?

There will be a Retro Performance Level (going from 0 to 15 and beyond) introduced that will range from very low-tier hardware to top-tier hardware (such as, say, SteamBox specs). Libretro cores will be able to look at this level at runtime, compare it to the performance level of the box in question and thereby evaluate whether or not the machine it’s running on will be able to run the core at fullspeed. If it can’t, it will display a warning.
This console will be about libretro ports using the libretro API. Therefore, we can gut any part of the Linux distribution that we don’t need.
I strongly believe in zero dependencies and keeping everything as lightweight as possible. Cores are also designed with this ‘zero-dependency’ ideal in mind. Everything that a libretro core should need should already be baked into the core from the start, so that it isn’t necessary for us to ship a truckload of packages (all of which can be potential dependencies and maintenance hazards) into the main distribution. So that means that if a core requires libusb, libusb gets baked in. If a core requires SDL, either the SDL specific code gets entirely removed or SDL gets baked in. Zero dependencies and making sure as much as possible is contained within the same dynamic library as the core itself will make this game console model sustainable.
By keeping this limited to the libretro API, it will basically be no different from any other RetroArch port to any platform we have done before in the past, like the PS3, 360, and whatnot. It is the same concept, except this time we’re going to make it happen for all this commodity hardware that is around.

So what will all this take?

Time
Community support. More hands on decks for this project, the better – since we will need to cover a lot of hardware
Dedication and the will to see this through to completion. Not going the obvious sleaze-ridden entrepreneur route obviously puts us at a large commercial disadvantage to play on an even playing field but then having risks is all part of the fun and we think users can see behind the promises of most of these other projects anyway. We have had a consistent track record so far and we are not going to compromise on our core values now either.

So when will all this start?

So yeah, this announcement is a bit of a ‘jumping the gun’ type of affair, but I felt I had to say something. I felt compelled to make this post because I see a lot of Johny-came-latelys trying to make a buck for themselves by filling an obvious gap in the market, and I just want them to know about our plans and that there’s something coming up that will put all their ‘accomplishments’ to crap. Hopefully people have gotten wise at this point and they don’t buy into another Ouya. Then again, given the obvious sleaze associated to these Kickstarter-led ‘game consoles’ and the empty hollow platitudes and ‘dumbspeak’ (and most importantly the amount of money they can accrue), you never know.

This project will start being kicked into high gear after RetroArch v1.1 is released. If you are interested in helping out in any way possible, drop us a mail at [email protected]. This project is being started because most importantly we feel like doing it and not out of any sleazy attempt to ‘get rich quick’ or whatever the incentive is by most of these entrepreneurs. Hopefully our attempt to keep this ‘real’ and not branch off into entrepreneurial la-la land will be appreciated by endusers, developers and platform holders alike.