RetroArch 1.7.5 released

The latest article from the libretro team announces a new version of RetroArch: RetroArch 1.7.5 has just been released! Grab it here. or via Google Play Store (32bit) or for users with 64bit capable devices you can grab the new version here.

So what is new in this version?

  • Launch of Nintendo Switch version

This is definitely THE highlight of this release. The libretro team got a dedicated article for this:

https://www.libretro.com/index.php/retroarch-1-7-5-introducing-libnx-switch-version/

In short: Installation instructions and all the feature included in this first release for the Switch like

  • OpenGL support
  • Touchscreen support (for MaterialUI/etc)
  • Full networking support
  • RetroAchievements support
  • Game scanning
  • Split Joy-Con support
  • Core downloader
  • Runahead support
  • and 44(!) cores supported already

 

Further there are the following improvements in this new version:

  • Menu improvements: dropdown lists
  • Adaptive V-Sync implemented for OpenGL (Windows/Linux)
  • Improved Vulkan performance (especially for Nvidia cards): mailbox emulation: More details in  this blog article.
  • Easy recording/streaming options (for versions with ffmpeg support)
  • UDP Streaming to another RetroArch instance

For all the details and changelog read the full blog post here.

 

RetroArch: Discord integration coming

The next release of RetroArch, which will be 1.7.4, will come with the integration of Discord. Discord is a free voice and text chat for gamers. Visit their website here on discordapp.com.

Here is what the blog entry from Winneon says:

RetroArch 1.7.4 will have extended Discord RPC integration! Previously before 1.7.4, RetroArch would act as any other game in Discord: as a simple “Playing” status that said you had RetroArch open. It wasn’t very descriptive or helpful other than displaying the name “RetroArch”. With the 1.7.4 update, RetroArch will display more information beyond a simple “Playing” status! Below is the full list of new features this new extended integration brings.

  • A new “In-Menu” and “In-Game” status that displays whether you’re in the standard RetroArch menu, or playing a game in a libretro core.
  • Playing & paused indicators displaying whether or not the currently running core is paused or not.
  • Sleek icons based on the Monochrome XMB theme that display what platform your game is running as. This is dependent on the core, not the individual game/content, so there will be case scenarios where it may be wrong (i.e. showing a GameCube icon when you’re playing Super Mario Galaxy in Dolphin).
  • A text indicator that displays what platform & core you’re playing under when hovering over the platform icon.
  • A text indicator that display what game/content you’re playing. If you chose your game/content from a playlist, it will use the playlist entry’s name instead of the content filename.
  • A counter/stopwatch that shows your current session’s playtime when you’re playing a game/content in a libretro core. The counter will pause when the game/content also pauses along with the new playing/paused indicators.

Source: https://www.libretro.com/index.php/upcoming-retroarch-1-7-4-details-on-discord-integration/

Lakka 2.1.1 with Raspberry Pi 3 B+ support

After quite some time the Lakka team released the new version 2.1.1 which – as you probably guessed from the headline – supports the new raspberry Pi 3 B+. Great news for these owners. Some updated and also some new cores like Higan, nSide, Cannonball, MAME2003 and much more.

Here is the changelog:

  • Important updates
    • RetroArch 1.7.3
    • LibreELEC 8.2 fixes
    • XU4 kernel update to 4.14
    • Rockchip kernel upgrade
    • Allwinner kernel upgrade
  • New cores
    • Higan, the famous SFC emulator from byuu
    • nSide, a fork of higan v106 with additional features
    • Cannonball, an enhanced OutRun engine
    • MAME2003 plus, updated 2018 version of MAME (0.78) for libretro. with added game support and improvements
    • Snes9x 2005 plus, Snes9x 1.43 plus BLARRG APU
    • FreeIntv, Mattel Intellivision emulator
    • Game Music Emu core
  • Core updates
    • Citra, the 3DS emulator
    • ChaiLove, the chaiscript game engine
    • MAME2003, the multi arcade emulator
    • PPSSPP, the PSP emulator
    • Sameboy, the Game Boy emulator
    • Desmume, the Nintendo DS emulator
    • and many more
  • Fixes
    • Keyboard fix for ARM based devices
    • Bluetooth fix for S905/S912
    • H3 boot
  • Bonus
    • Support for more gamepads (Zeroplus based gamepads)
    • Support more Commodore cores
    • Libretro overlays are now exposed in SAMBA
    • Project cleanup
    • XU4 fix display of the partition resize messages

For more information, head over to their blog post.

To update, use the internal update feature of Lakka. Download and reboot.

Libretro Status Updates

After the news about of the Dreamcast core Reicast yesterday, there is a general update from the Libretro team focusing on Dolphin, Ishiiruka, Beetle PSX HW and WIMP. Lets have a look:

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.

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!

Source: https://www.libretro.com/index.php/libretro-status-updates/

Reicast Libretro: Updates 26-7-2018

Again news from the Libretro team for Reicast. See their blog for details.

 

Here is a listing of all the changes/fixes/improvements:

  • (Dreamcast/Compatibility) Eldorado Gate – Broken opening FMV fixed (link)
  • (Dreamcast/Compatibility) Demolition Racer now works (link)
  • (Dreamcast/Compatibility) Redline Racer – Graphics bugs fixed (link)
  • (Dreamcast/Compatibility) Fixed rendering issues with Tokyo Xtreme Racer games (link)
  • (Dreamcast/Compatibility) Conflict Zone – Modern War Strategy now works
  • (NAOMI/Compatibility) Metal Slug 6 now works without graphics bugs

 

Reicast OIT – Increased compatibility with AMD/Intel GPU drivers

AMD GPU owners on Windows/Linux and Intel HD users on Linux/Mesa should probably be able to use the Reicast OIT core now, as several GLSL compliance bugs have been fixed by now.

Note that Reicast OIT can still be very buggy for Intel HD users on Windows, and slow to boot. The renderer really lends itself better to discrete GPUs from AMD/NVidia.

 

Render to texture upscaling!

Previously, games which rendered to texture (such as Dead or Alive 2 or Crazy Taxi) would always output at 1 x native resolution. Now, you can set the upscaling factor. Games which render the screen to a texture should look much better as a result, provided your GPU is up to the task.

xBRZ Texture upscaling

This new setting allows you to upscale all the textures in a game up to 6 x their original resolution using the xBRZ texture filtering algorithm! See it in action with Shenmue in this video below:

Source

4DO: 3DO libretro emulator supports now arcade games

The libretro core of the 3DO emulator 4DO supports now finally arcade games. As you can see, there are even playable games. The lightgun can be emulated by using your mouse.

From the blog:

After recently involving myself in the 3DO emulator 4DO I started looking over miscellaneous 3DO forums. Over at the Arcade-Museum.com forum I came across a post by willkaotix of klov who had the 3DO based arcade game Shootout At Old Tucson and had desoldered the ROM with an interest to get it dumped. This was back on 2015-10-18. Having not seen a conclusion to the thread nor the ROM floating in the wild I reached out to willkaotix.

willkaotix got back to me and having realized he had the ability to dump the ROM himself he did so… and here it is: 3do_arcade_saot_rom.zip

  • filename: 3do_arcade_saot.bin
  • size: 524288
  • crc32: b832da9a
  • md5: 8970fc987ab89a7f64da9f8a8c4333ff
  • sha1: 520d3d1b5897800af47f92efd2444a26b7a7dead

I’ve added support for the ROM in LibRetro’s 4DO core. This enables the loading, but currently not the playing (see below), of the publicly available dumped 3DO arcade games: Shootout At Old Tucson and Orbatak. The reason these games are not currently playable is due to these arcade games using custom controllers but there is an effort to reverse engineer them. It was/is possible to use the patched FZ-10 BIOS as well to boot these but for completeness it is nice to have this dumped finally.

Things of note: the BIOS is half the size of retail units. It has no attract mode. Retail games will not boot when using it.

Source: http://spawn.link/3do-arcade-saot-bios/

Naomi support in libretro Reicast cores

The libretro team shared the news about an exciting new feature: Their Reicast cores, both Reicast and Reicast OIT, support now Sega Naomi arcade games.

What is Sega Naomi?

Naomi was an arcade videogame system based on the Sega Dreamcast hardware and the successor of the Sega Model 3. While being nearly identical in terms of architecture, it did have double the RAM and fillrate of the home console version.

Naomi became one of the longest lasting arcade systems to be used second only to the Neo Geo AES. Various licensees (such as Capcom, Arc Sys, and even Nintendo) licensed the hardware during its lifespan to produce arcade games with.

How to use it

You will need a NAOMI BIOS file inside your system directory. The BIOS with the best compatibility so far is epr-21576g.ic27. This is a file that is contained inside the MAME NAOMI bios zip. Rename this file to naomi_boot.bin and move it to your ‘system directory/dc directory.

Try to get the file epr-21576g.ic27.

What content to use

You will need roms that worked on nullDC Naomi. These will typically be .dat/.lst or .bin/.lst pairs.

The last value of the .lst file specifies the size of the .dat/.bin file in hexademical value.

Here is an example of the .lst file used for Toy Fighter –

Toy Fighter
“Toy Fighter.dat”, 0x0000000, 0x05800000

You can find the existing .lst files here.

NOTE: MAME ROMS won’t work (yet). Proper Atomiswave roms won’t work, however, most Atomiswave to Naomi GD-ROM conversions should at least work or boot.

Currently existing issues

There are some issues that remain with Naomi support:

  • By default, two arcade sticks are hooked up.
  • There are some video and syncing glitches right now. One of the most immediately apparent is the flickering Naomi boot screen.
  • There is no analog and/or shoulder button support yet for Naomi games.

Videos

Toy Fighter

Dolphin Blue

King of Fighters XI

Dead or Alive 2 Millennium

Street Fighter Zero 3 Upper

A new core option called ‘GD-ROM Fast Loading Mode’ has been added. It can severely cut down on loading times, sometimes even removing them almost entirely as can be seen in the game ‘Daytona USA 2001’ here.

Various sound fadeout bugfixes

Through some judiciously applied hacks, the following games no longer suffer from sound fadeout issues:

  • Border Down
  • Bomberman Online
  • Chaos Field
  • Death Crimson OX
  • Fatal Fury/Garou: Mark Of The Wolves
  • Jet Set Radio/Jet Grind Radio
  • Napple Tale
  • Phantasy Star Online
  • Phantasy Star Online Ver. 1
  • Radirgy
  • Segagaga
  • Sonic Shuffle
  • Trigger Heat Exelica
  • WWF Royal Rumble

Graphics fixes

Thanks to the awesome efforts of flyinghead, several graphics glitches have been fixed, like Virtua Tennis or Psyvariar 2.

Other changes

Reicast OIT

  • Added an accumulation Pixel Buffer Size core option. You can set this to 512MB, 1GB or 2GB, depending on how much VRAM your video card has. For higher resolutions to output correctly, you might need to increase this to the highest value possible.
  • House Of The Dead 2 failed a verify assert – should boot and be playable now.
  • Rebase ADPCM decoding.

Reicast (non-OIT)

  • Multipass rendering is now enabled by default. Plenty of games need this for accurate rendering and the performance tradeoff should be minimal.
  • House Of The Dead 2 failed a verify assert – should boot and be playable now.
  • Rebase ADPCM decoding.

Source: https://www.libretro.com/index.php/reicast-libretro-now-supports-naomi-other-additions/

 

RetroArch 1.7.2 released

As announced roughly a month ago, the RetroArch team released their new version 1.7.2 with the runahead latency reduction functionality which should provide even a better latency then the original hardware. How it works, which systems are support and more of the release, see libretro’s blogpost.

To download the latest release, go here or Google Play store.

Runahead latency reduction – better latency than the real hardware

A visual representation by Durante of how the runahead system works in practice.

This might just be our biggest release yet, thanks in no small part to the new runahead latency reduction system. This feature has already been all the rage over the Internet. Well known people like Durante of DSfix fame praised it and the popular site Ars Technica has dedicated an entire article to this game-changing feature.

We ran an article on this new feature before, and since then, several facts have changed on the ground which bears pointing out. First of all, several performance improvements have been made since. Secondly, the feature has now been enabled for the vast majority of the RetroArch platform ports.

The versions that have this feature enabled and exposed now includes:

  • PlayStation3
  • Xbox OG
  • Wii
  • WiiU
  • Nintendo Switch
  • Android
  • PC (Windows)
  • PC (Linux)
  • macOS
  • iOS

Here are some basic things you should know:

  • Every game has a certain built-in amount of lag frames. In order for the runahead system to perform as expected, you should set it to the same amount of frames to read ahead that the game you’re running is working by. So, for example, if a game like Super Mario World for the SNES has a guaranteed 2 frame input lag, for the best results, set Runahead frames to 2.
    You can count the amount of lag frames a game has by using the frame advance feature in RetroArch.
  • For playable performance, your system should be at least capable of running the core at twice its regular speed. These performance demands go up commensurate to the amount of frames you want to run ahead. The higher performance you get with a core, the more frames you can run ahead at fullspeed.
  • While the runahead system is core agnostic and therefore technically we don’t need to patch up cores in order to work with the runahead system, there are several things that can be done in order to improve performance considerably. To this end, Dwedit has submitted several patches to some of the cores in order to make them perform much better. Some of these cores include (but are not limited to) the Snes9x cores, QuickNES, FCEUmm, Nestopia, Gambatte, and even Mednafen/Beetle PSX.
  • There are currently some things you should know about Mednafen/Beetle PSX when it comes to runahead. First of all, in order for this core to work correctly with runahead, you should use the software renderer. The OpenGL and Vulkan renderers are currently buggy with runahead. Second, even after several savestate performance improvements, it is unlikely you will be able to set runahead to higher than 1 frame while still being able to run at fullspeed. This might likely change once our bounty for the Beetle PSX dynarec is finally fulfilled (and on that note, it has already reached $720, and a coder is working on a potential solution)
  • An often heard question that has been asked is – will this work on a Raspberry Pi? There is no straight answer to this since it heavily depends on the core’s performance. Based on our performance tests on the PS3 and Xbox OG, QuickNES and Gambatte should be at least two cores that should run at fullspeed with runahead set to 6 frames or less. Your mileage may vary on any of the other cores. The quick rule of thumb is that the faster the core, the higher chance there is to get it to run at fullspeed with more runahead frames.

How to check the amount of lag frames a game has

RetroArch has the ability to pause a core and advance it frame by frame. Perform the following steps to determine the amount of lag frames of a game:

  • Pause emulation (press ‘p’ button on keyboard).
  • Press and hold the jump button on the controller.
  • Advance emulation frame by frame (press ‘k’ button on keyboard) until the character jumps.

The number of k presses before you get a reaction should be the number of lag frames you can safely remove with run ahead.

Performance, scalability

So, how well does all this scale? Of course, the more expensive hardware you throw at a latency reduction approach like this the better, but how low can we actually go in terms of specs and still obtain good results? To figure out a basic answer to this question, I decided to test the runahead system on two old game consoles that are not exactly powerhouses at this point. The first of the lot is the Xbox OG, powered by a fairly mundane Pentium 3/Celeron 733MHz CPU. The second is the PlayStation3. Its PPU is roughly equivalent to a Pentium 4 2.4GHz CPU in terms of real-world performance, and even that comparison is probably pushing it. So this is not exactly powerful hardware.

Street Fighter Alpha 3 FBAlpha 2012 No runahead 104fps PS3
Street Fighter Alpha 3 FBAlpha 2012 Runahead – 1 frame 57fps PS3
Mega Man 2 QuickNES No runahead 124fps PS3
Mega Man 2 QuickNES runahead – 1 to 6 frames 124fps PS3
Mega Man 2 Nestopia No runahead 124fps PS3
Mega Man 2 Nestopia Runahead – 1 frame 76fps PS3
Mega Man 2 Nestopia Runahead – 2 frames 54fps PS3
Super Mario World Snes9x 2010 No runahead 113fps PS3
Super Mario World Snes9x 2010 Runahead – 1 frame 78fps PS3
Super Mario World Snes9x 2010 Runahead – 2 frames 65fps PS3
Super Mario World Snes9x 2010 Runahead – 3 frames 56fps PS3
Sonic 1 Genesis Plus GX No runahead 116fps PS3
Sonic 1 Genesis Plus GX Runahead – 1 frame 51fps PS3
Bomberman 94 Mednafen PCE Fast No runahead 124fps PS3
Bomberman 94 Mednafen PCE Fast Runahead – 1 frame 83fps PS3
Bomberman 94 Mednafen PCE Fast Runahead – 2 frames 66fps PS3
Sonic 1 SMS Gearsystem No runahead 120fps PS3
Sonic 1 SMS Gearsystem Runahead – 1 frame 63fps PS3
Sonic 1 SMS Genesis Plus GX Runahead – 1 to 6 frames 124fps PS3
Mega Man 2 QuickNES Runahead – 1 to 6 frames Fullspeed Xbox OG
Mega Man 2 FCEUMM Runahead – 1 frame Fullspeed Xbox OG
Mega Man 2 FCEUMM Runahead – 2 frames Not fullspeed Xbox OG
Sonic 2 Genesis Plus GX No runahead Fullspeed Xbox OG
Sonic 2 Genesis Plus GX Runahead – 1 frame Not fullspeed Xbox OG

We consider any PC from the year 2005/2006 (whether desktop or laptop) to be significantly more powerful than either of those consoles, so these test results bode quite well for the scalability and feasibility of the runahead method.

Features like the runahead system will also naturally increase the demand for ever faster cores so that people on lower specced hardware can use runahead with more frames in advance.

CRT Switch Res – GroovyMAME-like features for 15KHz capable CRT monitors!

Thanks to forum-user Alphanu, RetroArch now has the ability to query cores for their exact video timing data, which can be used to switch to native-resolution, 15 kHz modelines for use with standard-definition CRT TVs.

This is a big step for retro purists, as RetroArch can now output “pixel-perfect” video with accurate timing to compatible displays, even quickly switching between interlaced and non-interlaced modes on the fly.

This capability is currently Windows-only and requires modelines to be created in advance by CRT_EmuDriver or Custom Resolution Utility with a compatible GPU. Linux support is coming soon.

In case you’d like to learn more, follow these links:

Direct3D improvements, additions, and a new Direct3D10 driver

With RetroArch 1.7.1, we really stepped our game up to finally start treating Windows as a first-class citizen platform. You have seen this in the form of dedicated Direct 3D 11/12 video drivers that had the ability to run the same shaders as Vulkan, our new slang shader spec that is made possible by the impressive Khronos/ARM-backed project SPIRV-Cross.

Increased backwards compatibility

Previously, the Direct3D 11 driver required that your graphics card driver supported at least Shader Model 5.0. We have since downgraded this requirement to Shader Model 4.0. As a result, I am now able to use the Direct3D 11 video driver on an old 2010 laptop GPU that only supports Shader Model 4.0 (it’s an ATI Mobility Radeon HD 4300). We also try to support more D3D11 feature levels instead of just defaulting to 11.0.

New Direct3D 10 video driver

On some systems, though, you won’t be able to make use of the Direct3D 11 driver no matter what. One of those systems happened to be another old laptop I had lying around here. This one has a Geforce 9200M GS, and the specs state that it supports up to Direct X 10 and Shader Model 4.0. Direct3D 11 is a no go on this GPU even with the increased backwards compatibility.

It’s for this purpose that me and aliaspider spent some time to finally make the Direct3D 10 driver feature-complete. Direct3D 10 should be available from Windows Vista and up, whereas Direct3D 11 is available from Windows 7 and up. The Direct 3D 10 driver should be feature complete and identical to the Direct3D 11 driver, with the sole exception of hardware rendering contexts not being available right now with Direct3D 10.

Which brings us to the last Direct3D-related subject…

Direct3D-powered libretro cores are now possible!

This feature is easily worth its own article, but since we already covered this before and because 1.7.2 has so many huge features, we will relegate this to a side note. Nevertheless, it is none the less important.

Up until now, if you wanted to use hardware-accelerated 3D rendering in a libretro core, your options were OpenGL and/or Vulkan. There is now a third option – Direct3D 11, and the first libretro core that supports this is the PPSSPP core!

With all these features, we now have everything in place to really do an UWP version of RetroArch justice.

Input remapping system improvements

The input remapping system (available from Quick Menu -> Controls) had many obvious limitations previously. Some of these included:

  • It was not possible to map keyboard from more than one gamepad (for instance with Dosbox)
  • It was not possible to map more than one button to the same action
  • It was not possible to unmap buttons or analogs
  • It was not possible to map a button to trigger an analog response (for instance, in an N64 emulator, running in Super Mario 64 with the D-pad)
  • It was not possible to map an analog to another analog
  • It was not possible to map an analog to produce a button response

Most of these restrictions have now been lifted at long last thanks to radius, and the visual representation is also much improved now.

To read more about this, also visit the related forum thread here.

Do note that all your existing remap files are now obsolete, and you should start from scratch. This was a necessary evil unfortunately in order to progress.

Various Quality-Of-Life improvements

We have tried to do various consequential Quality-of-Life improvements for this release:

    • XMB and MaterialUI menus should scale much better now depending on the output resolution. Previously, the XMB and MaterialUI menu elements were too small if you were running at a resolution of 1440p or 4K.
    • Boxart / thumbnails now react better to other elements on the screen and can resize or adjust themselves accordingly. There are also new ways of showing a thumbnail on the left and right side of the screen in XMB. It is also possible to determine what ‘type’ of thumbnails get shown on the left and right, respectively.
    • There are two layout modes now for XMB – you can choose between Desktop and Handheld. Desktop is the default look of the XMB as it was now, mirroring the PS3 layout, while Handheld goes for an XMB look that is more in line with how it looked like on PSP. Previously, the default layout was ‘automatic’, where it would default to the PSP layout if you were running at a resolution of 320×240.
    • Shaders should work again with the Vulkan video driver on the Android version.
    • When you select a shader preset now, it should only show you the supported shader presets based on the video driver that is currently selected. In other words, it will no longer show you GLSL shaders and/or presets when you have selected the Vulkan video driver, just as an example.
    • Certain video features were never implemented for some platforms. We now hide features like Black Frame Insertion, GPU Hard Sync and Swapchain images if the video driver in question doesn’t implement them. It is conceivable that for some of these drivers, these features might be implemented later, but overall we feel it declutters the menu considerably by simply not showing settings that have no effect at all when toggled due to them being unimplemented.
    • We now expose certain convenience features on the Quick Menu, such as Latency, Rewind and Overlay settings. You can also hide these settings respectively by going to User Interface -> Views -> Quick Menu and disabling these categories.
    • The shader next/previous hotkeys are more intelligent now and deliberately skip over shaders that are not supported by the current video driver.
    • (For Linux users) Wayland should now have proper scaling with XMB menu driver.
    • (For Linux users) Allow compositor disabling on X11 fullscreen through _NET_WM_BYPASS_COMPOSITOR.
    • On platforms where this is supported, ‘Set Display-Reported Refresh Rate’ is a convenient way of setting the exact refresh rate that the OS/video driver has reported to the application. This might be more accurate than measuring the refresh rate yourself by waiting for 2048 samples or more before hitting the Action button on ‘Estimated Screen Framerate’.
    • Display Framerate is now moved to ‘Onscreen Display – Notifications’. A handy feature showing all sorts of statistics is now exposed in this submenu as well.

RetroAchievements updates

The future is now. Arcade achievements using the FB Alpha core are fully supported in this version. This brings support for Neo Geo and Capcom arcade boards (Metal Slug, Marvel Super Heroes).

– Capture your greatest moments with the automatic screenshot feature! Look back fondly on the time you grinded your RPG character to level 99 for internet points.

– RetroAchievements on a retro computer?! Windows XP builds of RetroArch now support achievements!

General changelog

ANDROID/OPENSL: Prevent crashes when setting audio latency too low (buffer count can never be lower than 2 now).
CRT: Added CRT SwitchRes.
COMMON: Hide the ‘Core delete’ option if the ‘Core updater’ is also hidden.
COMMON: Add way to reset core association for playlist entry.
COMMON: Fix invalid long command line options causing infinite loop on Windows
COMMON: Add OSD statistics for video/audio/core.
COMMON: Added runahead system; allows you to drive down latency even further.
COMMON: Fix buggy behavior that could happen with ZIP file reading on some platforms as a result of not initializing struct.
CHEEVOS: Support Atari 2600, Virtual Boy, and Arcade (only Neo Geo, CPS-1, CPS-2 and CPS-3 and only with fbalpha core).
CHEEVOS: Add option to automatically take a screenshot when an achievement is triggered.
CHEEVOS: Fixed incompatibilities with Neo Geo Pocket achievement sets.
CHEEVOS: Store only login token, not password.
D3D10: Added D3D10 driver to release build. Has working shaders (Slang), overlay, and menu display driver support. Should be on par capabilities wise with D3D11 driver except for there being no hardware rendering right now.
D3D11: Experimental hardware renderer. Allows for libretro cores to use D3D11 for hardware rendering. First core to use this is PPSSPP.
D3D11: Increase backwards compatibility, shaders compile with Shader Model 4.0 now, added support for more feature levels.
D3D10/D3D11/D3D12: Fix crashes with completely black or white thumbnail textures in XMB.
GUI: Support disabling window decorations on Windows and Linux.
LIBRETRO: Addition – Functions to enable and disable audio and video, and an environment function to query status of audio and video enables.
LOCALIZATION: Update Italian translation.
LOCALIZATION: Update Polish translation.
MENU: Add Rewind/Latency/Overlay settings to Quick Menu, add options to show/hide them (User Interface -> Views -> Quick Menu)
MENU/RGUI: Only show Menu Linear Filter for RGUI and only show it for video drivers that implement it (D3D8/9/10/11/12/GL)
MENU/RGUI: Add User Interface -> Appearance options.
MENU/RGUI: D3D8/D3D9: Hookup Menu Linear Filter
MENU/XMB: Disable XMB shadow icons by default for PowerPC and ARM for performance reasons.
MENU/XMB: Left/right thumbnails are now automatically scaled according to layout.
MENU/XMB: Add Left Thumbnails (additional to the right).
MENU/XMB: Fixed left/right tab regression.
MENU/XMB: Fix scaling of tall images that were cut on bottom previously.
MENU/XMB: Menu scale factor setting now changes texts length, image scaling and margins.
MENU/XMB: Mouse cursor scales correctly now.
MENU/XMB: Add toggle to show/hide Playlist tabs.
MENU/XMB: Add menu layout – can switch between Desktop, Handheld and Auto.
MENU/XMB: Don’t load menu pipeline shaders unless XMB is selected (D3D10/D3D11/D3D12/GL/Vulkan)
MENU/VIDEO: Only show black frame insertion for the video drivers/context drivers that support it (so far this includes – D3D8/D3D9, OpenGL, Vulkan)
MENU/VIDEO: Only show max swapchain images if supported by video driver and/or context driver (so far this includes – DRM EGL context driver, VideoCore EGL context driver, Vulkan)
MENU/MaterialUI: Automatic DPI Scaling should be much improved now, now scales as expected at 1440p and 4K resolutions.
MENU/MaterialUI: Fix wrong calculation of an entry height causing long playlists to end up outside of screen range. This also could cause crashes on low DPI screens.
IOS: Fixed crash when opening downloaded roms from Safari or using the “Open in..” functionality. Added the compiler flag to support keyboard remapping to controls.
IOS: Fixed buffer overlap that caused a crash while trying to download GLSL shaders from the buildbot.
PS3: fix URLS
REMAPS: Mapping keyboard keys from more than one gamepad (works with dosbox)
REMAPS: Mapping more than one button to the same action
REMAPS: Unmapping buttons
REMAPS: Unmapping analogs
REMAPS: Mapping a button to trigger an analog response (tested with mupen, can run on SM64 with the d-pad now, triggers a full analog tilt)
REMAPS: Mapping an analog to another analog (having more than one analog mapped to the same output causes issues)
REMAPS: Mapping an analog to produce a button response
SCANNER: Should be able to scan dual-layer Wii disc images now, filestream code now supports files larger than 4GB.
SHADERS/SLANG: Slang shaders should work again on Android version and MSVC versions (basically all the Griffin-based versions).
SHADERS: If GL context is GLES2/3/Core context, Cg shaders are unavailable. Applies to shader list too.
SHADERS: Hide cg/glsl shaders from being able to be selected if D3D8/9/10/11/Vulkan video drivers are selected.
SHADERS: Hide slang shaders from being able to be selected if D3D8/9/OpenGL video drivers are selected.
SHADERS: Prevent crashes from occurring if we have the GL video driver in use and we try to skip to a slang shader through next/previous hotkeys
SHADERS: Fix shader parameter increase / decrease functions
SUBSYSTEM: handle savestates properly (cart1 + cart2.state0)
VULKAN/X11: Fix X11 Vulkan bug from Wayland driver.
VULKAN: Fix multi-line text spacing in menus with Vulkan driver.
WINDOWS XP: Add Cheevos support.
WINDOWS/MSVC 2003/2005/2010/2013/2015/2017: Add Cheevos support.
VITA: Bugfix for ‘PS Vita takes many time to start to accept input’ issue.
X11: Allow compositor disabling on X11 fullscreen through _NET_WM_BYPASS_COMPOSITOR
X11: Prioritize NET_WM_STATE_FULLSCREEN in true fullscreen mode
WIIU: Fix OOB read/write in keyboard driver.

What’s coming next for RetroArch

So, RetroArch 1.7.2 had some pretty major new features, right? By all indications, it looks like RetroArch 1.7.3 will be no different. So let us give you some sneak peek at what might be arriving down the road for the next version…

A Qt-powered WIMP desktop UI!

Ever since RetroArch’s inception in 2012 (and even way before that when it was just known as SSNES), we have stuck to our guns and insisted on a uniform menu experience that obviously took its design cues from mainstream gaming consoles like the PlayStation.

While this lends itself very well to game consoles and the like, there is also a very vocal minority (or majority, depending on how you look at it) that has definitely made it well known that they would really prefer a native WIMP UI at times to be able to do mundane tasks like select/load a ROM, or browse through a playlist easily with the mouse, etc. And certainly, an argument can be made that on a traditional desktop PC, it might not be ideal at all times to be confined to the same kind of input limitations as say a traditional gamepad.

For 1.7.3, the way we will try to reach for a concession with these users will be through the way of this companion UI. What you see in these screenshots will be a WIMP (Windows, Icons, Menus, Pointers) GUI powered by Qt. It will be available for RetroArch versions that run on PC Operating Systems like Linux, Windows and macOS.

The way we envision this UI to work is a bit like how it is possible in Steam to switch between Big Picture mode and the traditional desktop UI. We still want the console-style menus to be RetroArch’s main user interface and we believe this scales fairly well onto game consoles, mobile devices and handhelds. But there is no denying, as Windows 8 all taught us, that there is no such thing as one true universal UI that can scale well across every potential device, so the user should definitely have his/her options.

The two screenshots you see here are not just mockups, they are already operational in bparker’s branch. What you see here is the result of about one solid month of work, and it’s already reaching quite satisfactory levels.

We have kept a tight lid on it until now, but felt the time was right to reveal more details about it. We are doing this primarily for the users, and we hope that they will like it, and through designing this we are also trying to be more receptive to user feedback than we might have been in the past.

Despite all this, as with anything in our codebase, we do insist that from a programming point of view, that this will not impose any huge dependencies, and that all of these individual coding parts are modular in nature and can be easily compiled in or out of any build. With RetroArch we always have to walk a fine line between staying lightweight and not becoming perceived of being too bloated yet also trying to meet increasing user expectations, and it’s not necessarily always possible to be in the middle of these two opposing camps. So we try to do our best to satisfy both groups this way, and stay true to our design goals while also making sure that we keep the users happy who don’t care about the underlying codebase but just care about the results from an enduser perspective of what they can do with the program. It’s a big challenge and definitely a balancing act but we feel we have become better over the years in terms of finding the right balance.

2018 The Year Of The Libretro Frontend

Libretro, the underlying platform and ecosystem that powers most of what you see in RetroArch, will see an explosive growth throughout the rest of this year, both by our efforts and outside forces also only tangentially related to our project. You will see the Libretro logo not only in more places, but you will also see popular programs like Kodi finally adopting the API wholesale.

While it was never our direct intent to have our API be synonomous with retro gaming and emulators, we do not mind this being the biggest driver of growth in this emerging ecosystem and are grateful for the developments there.

RetroArch Roadmap for v1.7.0 and beyond

The latest news the RetroArch team shared on their blog is about some behind the scenes development and a brief roadmap status. Interesting also what kind of new platform the intend to support  (NES and SNES Classic, yeah) in the close future.

From their blog post:

Compatibility with OpenGL 1.x

From its inception, RetroArch’s OpenGL driver has targeted OpenGL 2.0 and/or later. There are a lot of people on ageing computers that don’t have a GL 2.x compliant driver. We have been putting a lot of work into modularizing the renderchain code, splitting it up from the main GL driver into their own files. This will pave the road towards a basic OpenGL 1.x renderchain which should at least work with OpenGL 1.3 and up. We might be able to target even lower versions later on, but time will tell.

Certain features this GL 1.x renderchain will not have:
* FBO support. FBOs wasn’t a thing with OpenGL until at least version 2.0 (not counting extensions). This also means no libretro GL support, so don’t expect hardware rendered cores with OpenGL 1.x.
* Shaders. Again, this is tied back to a couple of factors, one of them being the lack of FBO support which makes multi-pass shaders impossible to implement. But also, shaders are impossible in general for this 1.x mode. GL 1.x did not yet have shader support. Shaders didn’t become a thing until GL 2.x. GLSL/Cg/HLSL did not exist yet at this time and the entire rendering pipeline was fixed-function.
* There will be no fast framebuffer readback paths (in so far as that stuff is actually ‘fast’ with GL to begin with). No PBO support, which wasn’t a thing back in GL 1.x days. So expect slow screenshot taking and/or recording.
* VAOs (Vertex Array Object) and VBOs (Vertex Buffer Object) weren’t yet a thing until GL 3.x and GL 2.x respectively.

We have no idea yet when this will start working. The main issue is testing it on ancient GPUs that only have GL 1.x drivers.

Xbox OG/Xbox 360

For a long time, the Xbox OG and 360 versions of RetroArch and cores have been de-listed. This had several technical reasons, one of which being that it was a big maintenance burden and struggle to keep having to update all the separate Visual Studio solution files for these platforms. For all other platforms, we build cores using a universal Makefile, which typically contains one file (called Makefile.common) which conditionally defines which files are to be compiled in. By having to maintain some separate solution file, we need to update two files instead of one, and worse, having to start IDEs in order to edit them (or even worse), having to manually edit them with a text editor, which can tend to be error prone on top.

In order to do away with these issues, we have now reverse-engineered how we can still have a Makefile target for MSVC that uses MS’ compilers/linkers/assemblers from within the confines of a Makefile-based solution. Note that this solution does not depend on Microsoft’s nmake and uses plain make.

Now that we have accomplished being able to compile and link cores with MSVC without any MSVC solution file, we now feel the time is right to start reintroducing the Xbox OG and 360 ports.

The Xbox port work also feeds into several other things we have been working on concurrently, such as :

  • Better Direct3D support. Xbox OG will need Direct3D 8, whereas Xbox 360 needs Direct3D 9 + HLSL.
  • The latest compiler that can be used for Xbox OG is Visual Studio 2003, whereas for Xbox 360 this is Visual Studio 2010 (right now). To this end, we have updated a lot of core Makefiles to include targets for these platforms, and not just for the Xbox platforms, but PC as well.

Direct3D work – supporting more versions, etc.

In the past, we have had two separate Direct3D drivers – one for XDK (shorthand for Xbox platforms), and one for PC (Direct3D9-based). Because we intend on supporting the Xbox platforms again, we no longer want the maintenance burden of having two video drivers that essentially are similar in lots of ways. To this end, we have started modularizing the Direct3D driver so that multiple backends are possible to be implemented.

Not only is it possible to have a Direct 3D 8 / 9 codepath, but it is also possible to have separate renderchains. For instance, the Xbox 360 will be able to use the HLSL renderchain, whereas on PC the user has the option to choose between Cg (which would use the Cg renderchain), and/or HLSL (which would use the HLSL renderchain).

We also intend for there to be a fallback path to Direct 3D 8 in case your GPU and its drivers do not support Direct 3D 9 for whatever reason. Backwards compatibility is very important to us and it’s increasingly getting harder to keep supporting all of these various versions in one single codebase. These are unique challenges to which there is often not a clear-cut solution, so we have to improvise a little on the fly and do unconventional things in order to make this happen.

Windows 95

Brad Parker likes extending backwards compatibility of RetroArch to older versions of Windows, and this in turn makes our codebase more flexible so that we can keep the Xbox OG and 360 ports alive.

People might mistake this for taking up resources and time that could be better spent elsewhere, but the opposite is true – by setting up the foundation in our codebase just once, it will be automated and take care of itself from that point on. Also, there is lots of overlap between platforms. For instance,
the latest compiler that can still churn out binaries for Windows 95 is Visual Studio 2003. This incidentally happens to be the last compiler that can create binaries for Xbox OG. So already here we have overlap whenever we need to make a core compatible with MSVC 2003 and we have to create the necessary Makefile targets for it.

For Windows 95, we are thinking of defaulting to the GDI video driver instead of Direct3D since we assume that the kind of machines running Windows 95 typically would not have either a video driver with Direct 3D 9 support or a GPU that supports it to begin with. Windows 95 still supported DirectX so we should be able to default to ‘DirectInput’ as the input driver. Windows NT 3.5 will pose more of a problem here though – back then, NT did not have any DirectX support at all, so a DirectInput driver is not possible and we lack any other input driver that we could use. Windows Raw Input driver cannot work on this ancient NT version. We are not sure yet what approach we will take there.

Nevertheless, Windows 95 will be first out of the starting gates.

New hardware platforms we intend to support

We have obtained some new hardware over the past few months:

  1. NES/SNES Classic
  2. GCW Zero
  3. SteamLink

It is our intention to have this be part of our main release schedule in future releases. We understand that for a system like SNES Classic, a different approach will be required vs. just the usual ‘full fat’ version of RetroArch that people have grown accustomed to, and we will certainly be taking a long hard look at RetroArch Clover for inspiration on what we will do. Our first approach is likely going to be something similar to RetroArch Clover that ultimately piggybacks off Hakchi and which complements the main UI of the platform rather than trying to replace it.

RetroArch 1.6.7 -Released

RetroArch 1.6.7 just got released as a bugfix version to 1.6.6 which just got released the other day.

What changed? Here are the highlights:

  • Complete overhaul of the mobile User Interface! (MaterialUI)
  • Nintendo 3DS regression fix – all cores were running slower: This is actually the main reason why v1.6.7 was released so quickly

And this is the general changelog from 1.6.7

  • SCANNER: Fix directory scanning.
  •   CANNER: Fix file scanning.
  • COMMON: Fix ‘Disk Image Append’ option.
  •   REEBSD: Compatibility fixes for Video4Linux2 camera driver.
  •   UI: (MaterialUI) Add disk image append icons.
  •   UI: (MaterialUI) Improve word wrapping when menu icons are enabled.
  •   UI: (MaterialUI) Add User Interface -> Appearance -> Menu Icons Enable. You can turn on/off the icons on the lefthand side of the menu entries.
  • GUI: Performance optimizations for XMB menu driver – only calculates visible items.
  • LOCALIZATION: Update Italian translation.

In v 1.6.6 and 1.6.7  many cores got updated including

  • Snes9x 2005
  • Genesis Plus GX
  • Parallel N64
  • P-UAE
  • Beetle PSX
  • Beetle PC Engine Fast
  • Beetle PC-FX
  • Beetle Saturn
  • Beetle SuperGrafx
  • Final Burn Alpha
  • ProSystem

Get more details from here.