RetroArch 1.19.0 release

Libretro Team

RetroArch 1.19.0 has just been released.

Grab it here.

Remember that this project exists for the benefit of our users, and that we wouldn’t keep doing this were it not for spreading the love to our users. This project exists because of your support and belief in us to keep going doing great things. We have always prioritized the endusers experience, and unlike others, we have never emburdened them with in-app ads, monetization SDKs or paywalled features, and we intend to continue to do so. If you’d like to show your support, consider donating to us. Check here in order to learn more. In addition to being able to support us on Patreon, there is now also the option to sponsor us on Github Sponsors! You can also help us out by buying some of our merch on our Teespring store!

Changelog

We never got to release 1.18.0 so we’re moving straight to 1.18.0. Therefore we include all the changes for 1.18.0 as well.

1.19.0

  • AI: Revert AI translation to previous version (fix for translation not working with HW rendered cores)
  • APPLE: Try to use system preferred language
  • APPLE: Correctly register for filetypes uniquely
  • APPLE/MFI: improved Switch Online controller support through MFi
  • AUDIO: Bring back audio toggling on menu toggle
  • CHEEVOS: Build a default RetroAchievements memory map when no RetroAchievements game is loaded
  • CHEEVOS: Update to rcheevos 11.3
  • CHEEVOS: fix hardcore acting as if it’s enabled when it isn’t
  • CLANG: Fix clang error incompatible-pointer-types-discards-qualifiers
  • CLOUDSYNC/LINUX: Enable Cloud Sync by default on Linux builds with network (#16456)
  • CLOUDSYNC/WEBOS: Enable Cloud Sync by default on Linux builds with network (#16456)
  • CORE: Set compute fps stats logging to debug level
  • EMSCRIPTEN: Added M2000 to core selection dropdown
  • FFMPEG: Add compatibility with FFMPEG 7.0
  • GLSLANG: Remove unneeded ENABLE_HLSL code from glslang
  • GENERAL: Memory leak: Dynamic allocation from msg_hash_get_help_us_enum was not freed.
  • INPUT/KEYBOARD: Add support for multimedia keys – Extended RETROK_ values with 18 new items, commonly found on
    “multimedia” keyboards. Mapping added for SDL, X11, Wayland, dinput, winraw keymaps.
  • INPUT/MFI: Pressure sensitive left/right triggers
  • INPUT/MFI: Fix Start + L1/L2/R2 combinations
  • INPUT/MFI: Support strong and weak rumble
  • INTL: Fetch translations from Crowdin
  • INTL: Add Galician and Norwegian to list of languages
  • LAKKA: Display reboot/shutdown message also when not saving config on exit
  • LAKKA: Provide update URL and target name at buildtime
  • LIBRETRO: Add a debug message for the SET_ROTATION callback
  • macOS: Default Accessibility on if VoiceOver is on
  • iOS: default audio sync on again, also more mfi logging
  • iOS: Fix Import Content
  • iOS: Fix ios-arm64 nightly build crash
  • iOS: Import content from iCloud
  • iOS: Fix #16485 crash on startup
  • iOS: Display app icon in app icon picker in materialui
  • iOS/tvOS: Various QoL improvements
  • iOS/tvOS: Fix a couple more path name mangling bugs
  • iOS/tvOS: Better way of packaging Frameworks
  • iOS/tvOS: define PACKAGE_VERSION to be App Store MARKETING_VERSION
  • iOS/tvOS: Fix keyboard handling for app store builds
  • iOS/tvOS: Fix escaping the sandbox for jailbroken devices
  • iOS/tvOS: default accessibility on if voice over is enabled
  • iOS/tvOS: better way of reporting available memory
  • macOS/iOS/tvOS: enable text-to-speech using AVSpeechSynthesizer.
  • tvOS: Fix scaling for 720p
  • MENU: New function in Quick Menu: Add to Playlist
  • MENU/XMB: New theme: FlatUX, designed to merge FlatUI and Retroactive themes into a single, unified design
  • NETWORKING/RETROPAD CORE: Fix socket close method
  • PIXMAN: Update pixman-private.h – patch to fix build issue with musl
  • PLAYLIST: Cleanup ‘Add to Playlist’ (#16495)
  • SCANNING: Fix for scanning PSP ISOs (and probably few others)
  • SAVES: Fix core config saving
  • SAVES: Fix save new config name when core loaded
  • SAVESTATES: Increase save state chunk size for all platforms – Even a class 6 or class 10 SD card can handle reads and writes on the order of MB/s, which means a 4KB chunk size is just wasting time in syscalls. This could maybe be fixed with a buffering reader but I don’t feel comfortable tweaking libretro-common’s VFS to handle that. Instead, I thought it would be good to both remove an ifdef and increase the chunk size to 128KB. For cores with small states this will should make state saving virtually instantaneous, and for cores with large states it should be a 32x speedup.
  • VIDEO: Fix crash when using threaded video – for Mesa 23.2 and later
  • VIDEO/GL: Fix reinitialization of the threaded gl drivers
  • VIDEO/VULKAN: Add support for A2R10G10B10 HDR format
  • VIDEO/VULKAN: Implement HDR readback – screenshot support
  • WAYLAND: Ignore configure events during splash (fix not remembering window size)
  • WAYLAND: Use frontend signal handler to quit (fix quit by window close)
  • WAYLAND: Commit viewport resizes (window resize is more responsive)
  • UWP: Align MESA to alpha-2-resfix – Remove wrong resolution special handling for OPENGL
  • UWP: 4K fix: align MESA reading of ClientRect to retroarch procedure, this fixes max resolution being set to 1080p. As reading must be done inside an UI thread and is in fact an async operation which might delay frame generation, the reading itself is doen once and cached, give that changing resolution while the app is running is an unlikely corner-case use
  • WINDOWS: Windows mouse ungrab must release the mouse instead of confine it to the current desktop (#16488)
  • WINDOWS: Fix numlock/pause key release events

1.18.0

  • AI: Fix narrator language when AI translation and menu languages are different
  • DISK CONTROL: Add option to disable initial disk change
  • DISK CONTROL: Visibility option for disk control notifications
  • DRM: Fix mode vrefresh calculation. When using an interlaced/doublescan mode, the vertical refresh rate is mis-calculated.
  • EMSCRIPTEN: Fix mouse Y parameter translation in rwebinput
  • INPUT: Fix input state combos including R3 and false triggers of RETROK_UNKNOWN
  • INPUT: Add a new turbo mode, “Classic (Toggle)”
  • INPUT: Fix bind hold when axis does not rest at 0
  • INPUT: Limit axis threshold setting to sensible values
  • INPUT: Add Overlay Mouse, Lightgun, and Pointer
  • INPUT/ANDROID: Fix mouse grab behavior on Android
  • INPUT/LINUXRAW: Fix device name and hotplug reconnect
  • IOS: Minor iOS JIT availability information
  • IOS/TVOS: Pause application on applicationWillResignActive
  • LIBRETRO: Add Doxygen-styled comments to parts of the libretro API
  • LUA: Update Lua to version 5.3.6
  • MENU: Add sublabels for input bind common entries
  • MENU: Don’t load history and favorites if size is 0
  • MENU: Don’t disable fast forward when entering menu
  • MENU: Widget position, size, color, icon adjustments
  • MENU: Fix savestate slots in Qt UI
  • MENU: Reorder and reduce depth of User Interface menu
  • MENU/OZONE: Fix sidebar wraparound, visibility after config load, crash after playlist delete
  • MENU/OZONE: Fix sidebar and sublabel animations
  • OSX/MACOS: Fix crash on non-Metal build
  • OSX/MACOS: Add portable.txt as flag for portable install
  • REMOTE RETROPAD: add display for analog axes, indication of inputs already pressed
  • SAVES: Allow combining saves in content dir with save sorting
  • SHADER: Added rolling scan line simulation based on the shader subframe feature. This is implemented with a scrolling scissor rect rather than in the shader itself as this is more efficient although may not work for every shader pass – we may need an option to exclude certain passes. The implementation simply divides the screen up by the number of sub frames and then moves the scissor rect down over the screen over the number of sub frames
  • TVOS: Force asset re-extraction when cache is deleted
  • TVOS: Add history and favorites to Top Shelf
  • TVOS: Fix crash when history item does not have a label
  • UWP: Enable HAVE_ACCESSIBILITY for UWP builds
  • UWP: Allow UWP build to work with a modified version of Mesa Gallium D3D12
  • VIDEO: Add subframe shader support for Vulkan/GLcore/DX10-11-12, enabling shaders to run at higher framerate than the content
  • VIDEO: Fix restoring fullscreen/windowed setting when unloading override
  • VIDEO/VULKAN: Fix HDR with Vulkan after reinit
  • VIDEO/VULKAN: Remove the use of oldSwapchain
  • VIDEO/GL2: Fix OpenGL ES version detection
  • WEBDAV: Fixed SEGFAULT in WebDav task sync + type changes
  • WEBOS: Fix build, add core location on webosbrew.org
  • WIN32: Fix Alt+Enter not working when menubar is disabled

Introducing McSoftServe

Libretro Team

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

Libretro Team

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.