RetroArch – Page 39

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.

RetroArch v1.1 – What to expect

August 5, 2014October 18, 2015 Libretro Team

Here’s a rundown on what you can expect from RetroArch v1.1, the next version of RetroArch to be released. Please bear with us that it has taken us so long since v1.0.0.2 to come up with a new official release. This v1.1 version has been long in the making to ensure that this new version will be a big major milestone for RetroArch in general.

So, here’s what the release will comprise of –

Going all PSP – PPSSPP core

We have ported the popular PlayStation Portable emulator, PPSSPP, over to the libretro API. This marks the second big libretro implementation to be using libretro GL after Mupen64 Plus.

It is shaping up to be a very stunning release. Linux users will especially appreciate the changes we’ve made which makes it possible to run PPSSPP in DRM/KMS mode (something which wasn’t possible in standalone since glew has X11 dependencies).

We’re aiming for two modes of operation. One mode will be in which the PPSSPP core functions much like standalone – where it saves everything inside a main PPSSPP assets directory and you install games from PPSSPP’s GUI. The other mode is more like a headless mode – the way every libretro core has functioned up until now. Saves will be saved in .srm form and it will be possible to directly boot ISOs/PBPs/.BINs without having to install them first from a GUI. There’s something to be said for both modes of operation.

We of course take no credit for any of the real emulation work in PPSSPP – the only thing we take credit for is porting it to the libretro API. We take nothing away of the accomplishments made by this team and we hope that the libretro port can be pushed upstream once it’s done. Please pay them a visit at http://www.ppsspp.org/ and support their efforts to improve PSP emulation – they’ve already come a long way in the two years it has been public.

We’ve made some screenshots of the core in action which you can check out here and on Twitter. We’re striving to expose as many of PPSSPP’s features as possible through core options for headless mode operation.

Needless to be said, we think this will be one of the main standout features of RetroArch v1.1. Hopefully it will open up people’s minds about how RetroArch and libretro doesn’t necessarily mean retro-grade graphics – some of these games like Tekken 6 and Soul Calibur Broken Destiny don’t look far removed from their PS3 versions when upscaled to 2x or 3x. And to see it running as fluidly as it does in RetroArch without any audio breakup whatsoever or any frames dropped is a sight to behold.

The PPSSPP core will be available for PC (we’re aiming for Linux/OSX and Windows), and mobile (iOS/Android/Blackberry). After version 1.1 is released, we will research an Xbox 360 port.

Going all PSP – RetroArch PSP

Just having a PSP core would be one thing, but RetroArch v1.1 is going to go one extra mile by also simultaneously appearing on the PSP itself.

Nearly all of the credit for this port should go towards aliaspider- I played only a minor but crucial part in the proceedings. He has really done a bang-up job porting over a great many new cores over that are useful for the PSP, as well as improving the performance of existing cores so that they run well on the PSP.

Right now we have greatly improved the performance of FCEUmm, NXEngine, Gambatte, Mednafen PC Engine (and others) so that they run fullspeed at PSP. Please keep in mind that a PSP for general purpose code is about two times as slow as a Raspberry Pi. So you’re dealing with a very weak CPU here, and so it necessitates specific PSP-specific code to really get the most out of its performance. And thankfully the libretro API allows for this – the libretro API doesn’t prevent you from taking advantage of PSP-specific hardware features in order to speed up performance inside a core.

Aliaspider also made a port of TempGBA over to the PSP. This is a Game Boy Advance emulator based on gpSP Kai (itself based on gpSP – a now defunct emulator by Exophase). There’s also a preliminary port of the popular CPS2/Neogeo emulator, but it isn’t yet done. No idea yet if this core will make it for the v1.1 release.

Like hunterk’s previous blog post indicated, the portability of RetroArch is really coming into its own now. With the PPSSPP core, it will be possible to run RetroArch PSP itself. So essentially what you have is that RetroArch PSP can be made to run inside a PSP emulator which itself is being run inside a native platform version of RetroArch. How much farther can we go from here? The future only knows.

New cores

Several new cores will be appearing. We made a port of fMSX and BlueMSX to the libretro API. This was a home computer released in the mid-1980s that was backed up by a consortium of companies (among them a little company called Microsoft and another small fish called Sony). Oddly enough, while it couldn’t really be considered a major worldwide success, it was relatively popular in Japan and (of all countries) The Netherlands. This home computer is also noteworthy for receiving some of the first games Hideo Kojima made in his career, such as Penguin Adventure (one of the first games I ever played BTW) and Metal Gear 1/2.

There will be RetroKeyboard support for these cores to sweeten the deal, but we will also try to have some sane default configs for the RetroPad per-game for some of the more popular games.

There will also be a Vectrex core, Vecx. This was another ’80s game console, and the main notability of this game console is that it wasn’t using sprite rasterization but rather vector-based. For all practical purposes it could be considered the first real home console capable of ‘3D graphics’.

Lakka – a new GUI beginning

Lakka will appear inside RetroArch starting as of version 1.1. So far, users have been using a very low-fi menu called RGUI. It is perfectly scalable from low-resolution displays to high-definition TVs, but there’s no denying it looks very much like something you would expect from a DOS program.

Lakka will be a more full-featured eyecandy UI. It will require OpenGL support inside the RetroArch version, so expect this to be usable on RetroArch PC and Android/iOS/Blackberry (PS3 maybe if it makes it for v1.1).

In terms of features and appearance, Lakka looks a lot like the PSP’s XMB frontend.

In the future, more menu drivers can be added, each being tailored towards a specific enduser preference. We have made the menu code far more generic to allow for different implementations which doesn’t require the coder to rewrite all the settings logic again and again.

You can watch a video of a prototype in action here – keep in mind that this is still a prototype and that the final version will look a lot more refined. In case you wonder, the guy showcasing it here is one of the authors responsible for the Lakka GUI – Jean-Andre Santoni (known also as kivutar).

Audio DSPs / Software Video Filters

We already touched upon this in the previous blog post about RetroArch v1.0.0.3 (which has now morphed into version 1.1). This feature has been implemented and it makes it possible to apply audio DSP filters and video software fitlters to RetroArch’s audio/video output.

Blackberry 10

We received a Blackberry Z10 phone from Blackberry sometime ago. In return, we will fully support Blackberry 10 starting as of v1.1. A new audio driver has been written, ALSA QNX, which should be far more optimal than the OpenAL driver we had before. We also intend on writing a nice Qt UI which wraps around RetroArch itself.

I know there has been a lot of discontent among Blackberry users that there have been so few releases, but rest be assured, we’re working on it.

Revamped iOS / OSX ports

I finally bought a Macbook Pro, and so I’ve been spending a lot of work on the OSX / iOS ports of RetroArch as of late. We’ve revamped nearly all of the settings so that it is possible for settings to be exposed to WIMP menus. This will be put to good use in the OSX / iOS ports of RetroArch.

The iOS version will be totally revamped as well. Cjori was working with me sometime ago on Controllers For All support. Hopefully I will be able to approach him a week before release time or so that we can do some final beta testing before we put the final polished version out.

X-Arcade Tankstick support

I received an X-Arcade Tankstick courtesy of Xgaming, and in return this device will be fully supported. Android support will be added, and I will also look into making it possible to bind it in RetroArch as two separate game controllers instead of it being recognized as a keyboard.

After v1.1, I will look into adding USB input drivers for the PlayStation3, Wii and Xbox 360 ports so that we will be able to use the X-Arcade Tankstick on thosee consoles as well without using their proprietary gamepad converter (which costs an additional $30).

Revamped Android port

Lots of work still remaining on the Android Port. The input code has been totally revamped and it should be possible to map a new gamepad directly from the menu. New input overlays have also been made (such as a a default RetroPad overlay) which works quite well.

Maybe if we make it in time we can revamp a lot of the UI code as well using our new generalized settings code which should prevent code duplication issues in the future.

Improvements to existing cores

Lots of improvements have been made to Mupen64Plus since the last new release, as well as a lot of other cores. We will also try to bring over the MAME/MESS 2014 cor e to Android – this might not appear on the Google Play Store since this will increase the APK size by about 150MB or so – instead a more fully featured version might be available on our new website.

New server

Starting with the release of v1.1, there will be another big change – a new server (Virtual Private Server), and with it will come a buildbot. We will finally have the ability to do continuous integration tests and have daily builds for the cores and the RetroArch platform versions. The existing website will soon be moved over to the new host – the transition will be as seamless as possible to the user, so hopefully you guys won’t notice when we finally make the switch.

So when will it come?

The rest of this month will be spent by me and others feverishly working to get all of this stuff in a presentable state. We also want to do a fair bit of Quality Assurance so that this next big version will be very solid. The estimated release is somewhere in early September. A new release is contingent on all these different factors all coming together. In case some parts might take longer than expected, we might just drop a version of v1.1 with some of these features being added later. In any case, you shouldn’t have to wait longer than early September. Again, we’re sorry for some of the delays and announcements from before but we’re really trying to ensure here that this next RetroArch release will be a real big gamechanger and so the delays are justified from that perspective. Hopefully you’ll agree once it is dropped.

Also, I’m sure I neglected to mention a fair few new features as well in this writeup. In any case, there have been far too many changes since February of this year to sum up in one blog post. When v1.1 hits I will put up a more comprehensive overview of everything that has been added ,changed and improved.

RetroArch and 240p

April 1, 2014October 18, 2015 hunterk

I got my hands on an old CRT computer monitor (VGA, 31 kHz) this past weekend and wanted to play around with pushing out native-res, “240p” signals from RetroArch.

RetroArch doesn’t have any built-in resolution switching capabilities, but we can use the operating system’s built-in tools to handle the task. In Windows, that means using CRT_EmuDriver and a compatible GPU, while in Linux we can use xrandr from the desktop environment. You can also theoretically force resolutions via KMS, but I haven’t had any luck getting it going.

Since I’m running Ubuntu 14.04 (Trusty Tahr, LTS), I could add my custom resolution modelines to my xorg.conf and then choose between them before launching a game, but instead I am using launch scripts that add and set the desired mode at runtime. So, on my desktop, I have a little bash script that reads like this for SNES (EDIT: forgot a couple of things):

#!/bin/bash
xrandr –newmode “snes” 5.979 320 332 368 380 240 242 246 263 +CSync
xrandr –addmode DVI-0 snes // replace DVI-0 with your active display; you can find it from ‘xrandr -q’
xrandr –output DVI-0 –mode snes
wait 5 // this will ensure that RetroArch doesn’t launch before the screen fully switches resolution
retroarch –menu –fullscreen -c ~/.config/retroarch/snes.cfg \ // points to my pre-configured SNES controls 🙂
&& xrandr –output DVI-0 –mode 1024×768 // this will take us back to a normal resolution upon exiting RA

Notice that the last line only goes off once RetroArch closes, since it’s hooked to the launch command with ‘&&’.

RGUI automatically scales to the resolution and looks great. Oddly enough, I had to set my in-game aspect ratio to 16:15 to get everything to map up properly. Regardless, the results speak for themselves (these pictures are huge; click to check out the glorious full-res shots):

Super Mario World, native resolution, unfiltered.

The only problem I have right now is that RA is detecting a refresh rate of ~47 Hz instead of ~60, for some reason, so it’s playing a bit slowly/jumpy. I can get a normal game speed by turning on the ‘threaded video’ option, but that’s suboptimal and leads to jerky scrolling. Regardless, this is a good start and I’ll be working with Squarepusher to iron out the current issues. If anyone has any experience forcing resolutions in KMS, please leave a comment or drop by IRC at Freenode – #retroarch.

You can use the same process with arcade games, you just have to replace the script’s modeline with one that corresponds to the game’s native resolution.

RetroArch next release and more

December 22, 2013October 18, 2015 Libretro Team

By Squarepusher

It’s been a long time since the last release, and it’s been a long time since any news has been posted period.

The relaunch

So, first things first – yes, there will be a new release soon. I’m conflicted on whether to call it RetroArch 1.0 but I think we might as well get it over with so that we can have some kind of sane versioning from here on out.

We will relaunch on the Google Play Store. We still don’t know why we were pulled from the Play Store the last time, we never got a response from Google telling us the exact reason why they pulled us, and while this all sucks really badly and quite frankly makes me have second thoughts about committing myself too much to Google’s app store, we will try again. This time we have taken a few contingency measures –

Some GPL purists seem to want the option of being able to only have cores in RetroArch that are GPLv2 and/or GPLv3, but no cores which use proprietary non-commercial licenses. Rumor has it that this even led to RetroArch’s takedown from the Google Play store – the argument being cited was “license violation”. While it’s a quite spurious argument and I would have liked Google to have contacted me first so that I could have at least given my side of the story, we will meet these people half-way this time.
After the app gets installed, a popup disclaimer will show up. This asks you whether to remove the non-GPL licensed cores or whether to keep them. This is a permanent option and the only way to undo this is to get rid of your ‘user settings’ – upon which you get greeted with the same disclaimer again.
The logo has been redesigned by Agnes Heyer and it’s no longer a bog-standard Space Invaders icon. This is in case the takedown was over some copyright claim over the Space Invaders imagery being used. It’s still an invader, but at least it has a distinctive enough art style now as to make it “different enough”. Agnes also supplied us with some very nice handdrawn art that we’ll be using on the Google Play store.
Images from games running in RetroArch Android will no longer be on the store listing. Just in case we got pulled over that alone.

Anyway, hopefully this is sufficient to address all possible issues. Let it be said that if we get pulled again after this re-launch and Google doesn’t even have the decency to give us an e-mail explaining why they took it down, that will be it for me – I’m not going to continue republishing on the Play Store just because Google entertains random accusations of “license violations/copyright infringement” of whomever wants the app pulled. Google’s ‘public relations’ is quite frankly atrocious, not to mention insulting and demeaning since publishing apps on the Google Play Store is not free – we had to pay 25 dollars to be granted the “honor” by Google to get people to actually be able to install your app on their phones/tablets. Now granted, this is not yet as bad as Apple, but freedom this most certainly is not. I expect at least some very basic customer support for those 25 dollars instead of some “automated web form” that leads to nowhere.

Libretro/RetroArch going beyond traditional games/emulators

Anyway, with that negativity out of the way, I am very excited to finally uncover what I and others have been working on these past few months during the blackout. I have always maintained that RetroArch and libretro is about ‘more’ than just emulators and game ports, but to date there was not much to show for this claim.

I look at RetroArch not merely as a “frontend” for an application API, but also as a truly crossplatform architecture – something that abstracts input/video/audio/location/camera streams and lets you – the app creator – easily make use of these various streams to create very rich, full-featured applications without having to worry about which platform you’re developing for. Any game and/or emulator out there needs at least input/video/audio streams, and libretro/RetroArch so far has been catering to this need for a good few years now.

However, ever since the Wii and things like Kinect/PS Move, the videogames world is no longer as rigidly defined as it used to be, and some videogames are not even “videogames” anymore. Or, to put it more simply, just like art, nobody knows what a videogame is anymore. Thanks to motion sensors, cameras, and location-based sensors, we can do reasonably cool new things with a traditional 3D videogames engine that we simply weren’t able to do years ago because of the devices simply not having these kinds of hardware features at their disposal, and the infrastructure not being there.This kind of technology allows us to make stuff that can’t easily be shoehorned into pre-existing “game genres” like beat ’em ups, adventure games, RPGs, and so on.

So you’ve got things like augmented reality now establishing themselves thanks to mobile phones and tablets, and you’ve got peripherals like Occulus Rift resurrecting Virtual Reality from that early ’90s grave. You’ve got Sony dabbling with Augmented Reality on PS Vita and trying to get people energized and excited about that platform to no avail. What all these things have in common is that there’s no real easy way for a developer to be able to target all that technology here with ‘one codebase’, ‘one app’, through some ‘common’ interface. If you want to make a game/app utilizing all this stuff for most of the mainstream platforms out there (PC/Android/iOS/etc), you better be ready to invest some serious time into delving into every conceivable API there is and trying to work around insane platform limitations. There’s a big window of opportunity here to create a nice, crossplatform way to tap into all these features without having to resort to big, bloated APIs that all have to be duct-taped together to achieve the desired app.

For instance, if you want to develop a native app for Android right now that utilizes the camera and location services, you can forget about any easy NDK API interfaces being there. It’s all on the Java side and you’re just expected to come up with a big ‘hack’ which of course is not published anywhere. I had a look at the way OpenCV made camera access from the NDK possible and it just was not what I wanted – it was basically a big hack job in native land that would never really be scaleable and would require continuous maintenance. I also didn’t like how I needed to pull in this big monstrous SDK just to be able to access the camera.

So we came up with our own solution for this. It’s a basic JNI shim job and it’s compatible from Android 3.0 up to the latest Android version right now – 4.4.4.2. And it’s very, very fast. You basically pass a GL texture ID from C land to the RetroArch Java frontend side – it uses this ID for binding the camera framebuffer texture, and from there you can do with this camera texture whatever you want from within the confines of your libretro app.

We have made an example core that can instantiate a large amount of cubes with each face showing the camera screen. The only dependencies here are that it’s a libretro GL core, and that it runs from within RetroArch Android. There is no dependency on OpenCV, on any external “native C” camera shim driver library, etc.

The same goes for location APIs – it can’t be accessed from the NDK normally.

RetroArch slowly becoming suitable for AR applications

RetroArch Android – a camera test core that shows a collection of cubes all displaying the camera frame in real-time.

Here is where RetroArch comes in. Just like how input, video, audio have been abstracted and drivers have been written and implemented per platform – so too do we now have camera and location service driver implementations inside RetroArch.

The big plus point here is that you can write a core utilizing this stuff in a very platform-agnostic way – the only thing you have to worry about is implementing a bunch of callbacks, and RetroArch (the frontend implementing the libretro API) does the rest. You don’t have to worry about the Android camera driver behaving differently from the iOS camera driver and vice versa – you don’t have to worry about Android’s location API or the iOS/OSX location API – that all is handled by the frontend, you don’t need to worry about it. But you can still get access to location data streams and camera streams now all the same from within your GL app – with minimal effort.

Just like with the camera, Proofs-of-Concept have been made that demonstrate both GPS functionality working and camera functionality working. They tick all the boxes that to me define RetroArch – cross-platform, portability, fast, and above all, clean and slimline. The camera works on Linux (Video4Linux2), for the Emscripten WebGL port, iOS, and Android. The location interface has two implementations – one for Android (through the Google Play Services), and an Apple implementation that works for both OSX and iOS (in OSX’s case it should be even backwards compatible from Snow Leopard and up). Portability – in that both the camera and the location functionality gets exposed to the core through the libretro API. So the job of having to implement all this location functionality for every platform is totally outsourced to the frontend side – you don’t even have to think for that matter about your app being “for Android” or “for iOS”. Performance in that the camera driver that has been implemented for both iOS and Android is as fast as it could be. You’re simply binding the camera framebuffer to a GL texture ID and then re-routing that back to the libretro core where you’re able to do with this texture whatever you want – you could turn it into a skybox, or you could render it on top of every cube – and even instance those cubes (2 to the power of 16 no less) while still getting very high performance.

I’m fairly confident that with a few more tests we can easily demonstrate the potential of the libretro API to the outside world as something that is far more significant than simply “something that allows you to port emulators in a cross-platform way”, and I’m quite excited about being very close at realizing that goal. Existing users should not take this as a sign that the stuff they care about – emulators/games – is going to play a diminishing role – this is about being all-inclusive, about creating a big entertainment platform that allows the developer to do whatever he wants his multimedia applications to do.

Emulators

So, where does this leave the emulation side? The stuff most people still care about when it comes to RetroArch? Well, the Mupen64 libretro core has been steadily improving – right now most effort has been focused on improving the Glide64 video plugin. I still would have preferred things to be even more solid at this point but I’d say it is getting close for a first release – people should be aware anyway that this is a continual “Work In Progress” and that improvements will be made on an ad-hoc basis.

Anyway, I can’t quite keep track of all the cores that have been added since, nor do I really know whether it’s wise to dump in the MAME 2013/2010 cores into the main package since the MAME 2013 core alone is 123MB in size. This wouldn’t go down well with a number of users that have complained about RetroArch’s filesize – and the more cores that will get added, the bigger a problem that will be. Perhaps expansion APKs are a temporary solution but eventually I think we will need to have the equivalent of a ‘package manager’ within the app that can pull in cores remotely. I’m not sure who would have to do the hosting though because we already tried that approach once for the Windows port and it turned out to be both unmaintainable and too expensive – server cost-wise.

When the release gets made, I may do a backlog throughout all the updates that have happened this past half year so people have a better overview of exactly is new. Hopefully that time will be soon. As a post-mortem I will follow up the release (when it happens) with a post that covers all the UI improvements (and other improvements) that have been made.