Libretro details what cores will be available when RetroArch launches on Steam
Announced just about a year ago was the Libretro team's plan to release their emulator frontend RetroArch onto Steam. With the launch "coming soon", more information has been given in regards to what cores will be available, and why only ten of them are launching alongside the frontend. Mupen64 Plus Next, Final Burn Neo, Genesis Plus GX, Mesen and Mesen S, mGBA, SameBoy, Kronos, PXSC ReARMed, and Stella are the cores that will usable with the Steam version of RetroArch on launch, covering the N64, SEGA Saturn, PS1, Atari 2600, Game Boy, Game Boy Advance, NES, SNES, SEGA Genesis, and arcade platforms. The decision behind launching only 10 cores is due to the team wanting to limit issues and bugs that users might encounter by keeping things simple. More cores will be available in the future, and will be provided as free DLC. A Linux-supported version is also planned, but will not be available upon launch.
10 Cores Available On Launch Day
We are deciding to launch with 10 cores at launch. These cores have already been approved and uploaded on Steam. They are as follows:
There will be no ‘Core Downloader’ in RetroArch, or anything that is not hosted on Steam in fact. To obtain cores, you need to install cores separately that we provide as ‘DLC’. These are all free just like RetroArch itself.
- Mupen64 Plus Next
- Kronos
- PCSX ReARMed
- Stella
- SameBoy
- mGBA
- Mesen
- Mesen S
- Genesis Plus GX
- Final Burn Neo
NOTE: We need to stress – on its own, without installing any of the cores, the most you will be able to do with RetroArch is watch some movie files and playback music files through its builtin ffmpeg core. To make it do anything else, you will have to install cores.
Differences between regular RetroArch and Steam version
Apart from these aforementioned changes, there will be no substantial differences for now in the Steam version. We understand that even though we have consistently improved the User Experience and tried to make things more easily accessible that we will still be in for a lot of criticisms over the initial learning curve, so we’ve pretty much resigned to the fact that this will happen and will just brace for impact and try to do as much as what we can with the criticism that will inevitably be piling on. We will try to do our best to be as receptive to the feedback as possible with the thickest amount of skin possible, and try to suitably make some much needed UI changes.
This is also what helped inform our decision to go with 10 cores. We could have launched with over 60 cores, sure, but the ensuing fallout would have been a mess and it would have been near impossible to focus on bug reports and issues piling in. By focusing on 10 cores, we can do some much-needed Quality Control where issues inevitably get picked up, we can respond to it and in the process improve the quality of the core. This kind of isolated feedback time with a specific batch of cores is something we have found ourselves in the past always lacking, since it was always off to do the Next Big Thing as new features, cores, and other developments are made on an almost weekly basis. This gives us the much-needed time to focus on a specific batch of cores and polish them before we move on to the next batch of cores.
Source