Introducing McSoftServe

Hi there, everybody! I’m Jesse Talavera, a libretro contributor. I’m primarily known in this community as the author of melonDS DS, but I’ve got some other exciting projects in the oven as well. Today I’d like to share with you something new that I’ve been working on for some time. Introducing McSoftServe, an emulator for the Taylor C713 soft-serve machines. The C713 is part of a line of soft-serve ice cream machines popularized by a well-known American fast food franchise. These machines are noted for their reliability, ease of use, and maintenance burden. Here’s the experience you can look forward to:

  • No firmware images required! All functionality is provided by built-in equivalents.
  • A timing-accurate warming sequence.
  • Helpful error messages to get you back on track when the emulated machine fails.

McSoftServe is full of surprises, and I can’t wait for you to see them. You can get it directly from within RetroArch today!

Vircon32 joins libretro/RetroArch

Written by: Carra

Hi! I’m Carra and I created Vircon32, a new game console. My Vircon32 core was recently integrated into RetroArch, so I thought this could be a good opportunity to talk about both the console itself and my overall experience creating a Libretro core.

What is Vircon32?

Vircon32 is a 32-bit virtual console that I designed from scratch. This console has been designed to be as simple as possible (to keep it accessible), but retaining enough features to allow for interesting games to play.

It is based on the 32-bit generation of home consoles (PSX, N64 and Saturn) but it has some modern “quality of life” features, like a 16:9 screen. In terms of power you could roughly think of Vircon32 as a PSX, but with no 3D capabilities. This console focuses on 2D instead, since even a minimal 3D engine would add too much complexity for a simplified machine like this.

If you are wondering how Vircon32 games look like, here are some screenshots.

Game screenshots from Vircon32

Game screenshots from Vircon32

Why did I do this?

Classic consoles are quite convenient to play: just insert the game! I’d love to have more new, retro-style games, but making games for old consoles can be quite challenging. This is because even something as basic as an NES is actually quite more complex than we think (and way more complex than Vircon32!).

Another option would be “fantasy consoles”. There are quite a few, but sadly most of these get abandoned early or have no games. And the most successful ones (Pico-8 and TIC-80) are too retro for the taste of most players. In my case I’d rather have polished, full-fledged games than experiment with 8-bit restrictions.

Game screenshots from Pico-8 (left) and TIC-80 (right)

Game screenshots from Pico-8 (left) and TIC-80 (right)

Libretro: Going universal

I’d like Vircon32 and its games to be enjoyed by as many people as possible. To this end the console and its games are free and open source. But this is not enough: getting to play Vircon32 should be easy. And for that I need it to be playable in as many platforms as possible.

I was able to make my emulator work in Windows, Linux and Mac. But not everyone will use a PC. What about smartphones and tablets? What about emulation handhelds? For that type of compatibility the easiest way was to develop a Libretro core.

What Libretro can do for you

Libretro is a programming interface. Its overall concept is simple: there is a front-end acting as a manager that will load and run “apps” called cores. Each core is a back-end that will exchange a series of messages with that front-end. Front-ends will take care of most system-specific tasks (initialization, timing, event handling…) and that makes cores much more platform-independent than regular programs.

There are several widely used systems with Libretro front-ends: RetroArch, Kodi, EmuVR… and they usually work on a wide range of platforms. This means that just having a Libretro core can make your content available in many different systems. And from a user’s perspective you also gain the benefit of convenience, since they can access tons of content all from the same place.

Last but not least, working as a Libretro core can give you access to several extended features. Some of them, like screen filters, come totally free. And with relatively low extra effort you can add things like savestates, rewind or netplay.

Vircon32 integrated in EmulationStation

Vircon32 integrated in EmulationStation

How hard is it to make a core?

This may vary for everyone, so I will write about my own experience. I believe that if you have some experience in programming, especially games, you should not find it hard to understand the Libretro API and the concepts is uses. However, be warned that the learning curve can get steep at the beginning until you find out where to start and get the general idea of how a core works.

There does not seem to be any good introductory guide showing a general explanation of how a core works, and the basic flow of messages for a minimal core. Other than a couple of samples at Github, most API features are only explained on the code comments in libretro.h. But of course libretro.h is huge, so all that info can be relatively useless for you until you know what to look for.

Also, keep in mind that many of those comments explain the feature but don’t tell how a core is supposed to use it. You will be expected to look at other cores and “reverse-engineer” what you need to do. Know, however, that most cores are quite complex. It won’t easy to isolate what you are looking for, and you can never be sure if a particular core is doing things the intended way, or using a weird hack.

Getting integrated in RetroArch

Creating a core is useful, but most users won’t actively go find and download your core. They expect to either have the cores they need preinstalled, or be able to download them automatically within RetroArch. You can have that getting your core integrated into RetroArch repositories. But know that this can take a substantial amount of extra work and time.

First you will need to have an online code repository that can be mirrored. You will also have to adapt your build system and learn about the YAML templates that libretro uses. After that, get ready for a good amount of testing. How much will depend on how many different systems you want your core to support. You will also need to prepare a core info file and get it merged. Along the process you may be talking with a few different people for each part of the process, but you can get help from them as well.

In my case, integration was a harder process than usual because I was not trying to integrate a new core for an existing console (like say, some new Game Boy core). Instead I wanted to add a whole new game system to RetroArch, and this involves some extra steps: a game database, thumbnails, the bios when needed, etc.

Build process for RetroArch’s cores: the Libretro Buildbot

Build process for RetroArch’s cores: the Libretro Buildbot

Road for the future

The current Vircon32 core is already compatible with all console games, but in terms of features it is still pretty basic. In time I plan to add a few more advanced features to it. Must haves for me are frameskipping and savestates. Eventually, if possible, it would be nice to also have rewinding and netplay.

About the console itself, the most important areas are already finished: the design is final, it is fully documented and there are working emulators and development tools. Even if all of these can be expanded and improved, the most clear path for Vircon32 to improve is to have more games, and better games!

Also on Steam

The core is also available on Steam here.

Libretro Core Updates – New version of Mr. Boom


MrBoom got a few improvements thank to SimpleTease, Zaac and Parsec:

  • It now supports 16-bit rendering depth to run flawlessly on an RG350M/OpenDingux
  • A Christmas easter egg in the menu was added
  • the medals and victory scenes got improved for team games
  • you can now skip being contaminated by a sick player by jumping on a kangaroo
  • There’s an improved invincibility/disease blinking.

You can get this new version on RetroArch’s Core Downloader as usual.

We’re looking for a graphic artist to implement a brand new level. If you’re interested, please contact https://twitter.com/frrancck

Flycast WinCE has merged into regular Flycast – only one core now! Plus – Switch port teaser!

So, flyinghead finally feels confident enough that we are at a stage where the WinCE branch can be merged into master.

This is a pretty big deal. This marks the first time that an open source Dreamcast emulator has Windows CE support in a mainline release, along with arcade Naomi support. Right now, the only other emulator that manages to emulate both these is a closed source emulator called demul. So this is a pretty big milestone for us.

So, what do you have to do from this point on?

– Go to the Online Updater, select ‘Update Cores’, and download ‘Flycast’.
– Remove the old Flycast WinCE core. It no longer serves any purpose, you can just download the Flycast core instead which was Windows CE support now built-in. If you have any games in your old playlists that still use the Flycast WinCE core, reset the core association and make it use the main Flycast core now.

This has been a tremendous undertaking and in the process, so many improvements have been made as a result:

* (Windows CE) The reason why the Windows CE build was separate before was that the addition of the MMU codepath would greatly hurt the performance of every non-Windows CE-based game. This is no longer the case thankfully. Instead, performance has actually improved over the non-Windows CE build from before (see the next point).
* (Optimizations / Performance) Thanks to SSA optimizations, performance is better across the board now for every game, whether it is a Windows CE-based game or not. We figure it’s about 30% faster on average give or take.
* (Libretro core-specific) Certain core options now get hidden depending on other settings that are turned on/off which they are dependent on. For instance – ‘Show VMU Display Settings’ – if you enable this and then leave the Quick Menu options screen and re-enter it again, it will show all the VMU display options. Turn this off and repeat the same process in order to hide all the VMU display-related options again. This will greatly unclutter the options list.
* (Libretro core-specific) A new setting that appears when Threaded Rendering is enabled – ‘Delay Frame Swapping’. This waits until the frame is rendered by the digital video encoder which means it’s being displayed on the screen. This helps avoid displaying bogus/empty frames that would not be shown on a real console. Without this option enabled, you can get heavy screen flickering with some games (such as South Park Chef’s Luv Shack and NFL Quarterback Club 2000).
* (Libretro core-specific) Auto-configuration of early input polling when threaded rendering is enabled. Threaded rendering needs early input polling configured or else input will be buggy. In the past, the user needed to do this manually on RetroArch, which greatly complicated things. Now instead, we do this behind the scenes through a private libretro API extension, so you no longer have to tediously configure this yourself. It was annoying and could mess with your configuration since for other cores you would really want to set it to late input polling for the best input latency.
* AICA sound emulation has greatly improved and can now be considered mostly feature complete. We have included a before and after comparison of Skies of Arcadia so you can get an idea of how much of an improvement it is – this is Skies of Arcadia before and after implementing the LPF (Low-Pass Filter) –

Before –

After –

So, in short, the low-pass filter has been implemented. This filter has an envelope, similar to the already implemented one for amplitude. It varies the cut-off frequency for attack/decay/sustain/release. The other thing added is the pitch LFO, which is used to create a vibrato effect. So far, the only sound inaccuracy I have noticed in a game is that certain music that is triggered upon events (such as in Resident Evil Code: Veronica) does not get properly faded out. Apart from that, sound accuracy has seen a tremendous improvement, really night and day in a lot of respects in games like Resident Evil 2 and Skies of Arcadia.

* (AMD) Per-pixel alpha sorting has been fixed on AMD GPUs. Previously ,it would look like this on Windows (at the main BIOS menu) –

Switch port teaser

Flycast Libretro is coming to RetroArch Switch courtesy of Datamats! For now it uses the interpreter core only, but m4xw is going to work on getting the dynarec working. No ETA and don’t bug the devs about it until it’s done!

Libretro Status Updates

So, what have we been up to?

Dolphin and Ishiiruka cores

The Dolphin libretro bounty has led to this rebasing of the Dolphin libretro core. It is now up-to-date with the latest sourcecode, and it now supports OpenGL, Direct3D11 and Vulkan! It is even available for RetroArch on Android right now, provided you use the AArch64 version (since Dolphin itself requires a 64bit CPU on Android anyway).

In addition to this, I have also taken a look at porting Ishiiruka (a Dolphin fork) to Libretro. This one is not as far along yet as the mainline Dolphin core, but we are already making steady progress with the OpenGL renderer!

RetroArch 1.7.4 – WIMP updates

There will continue to be improvements to the WIMP UI in RetroArch 1.7.4. One of the big new features will be a fancy grid view. Previously, the WIMP UI only had a list view.

Beetle PSX HW

Some important bugs have been fixed. Finally, mask bit emulation has been (hackishly) implemented by flyinghead for the OpenGL renderer, so Silent Hill’s fog finally displays properly. iCatButler has made PGXP much more robust over the past few weeks, which has led to many rendering bugs being fixed when PGXP is enabled.

Reicast

You can read about all of our improvements to the Reicast core in this separate blog post here.

Beam racing bounty – up to $1132!

The beam racing bounty has fetched $1132 so far!

RetroArch is already at the tip of the spear when it comes to latency mitigation strategies with features like runahead, configurable max swapchains, frame delay, custom video context drivers, etc. Beam racing is a new lagless VSYNC technique has been developed that is already implemented in some emulators like WinUAE. The aim of this bounty is to finally implement it in RetroArch as well, and the users/devs that want it have put their money where their mouth is for this particular feature!