RetroArch is looking for more translators

Libretro Team

Written by DisasterMo

As all here know, RetroArch is an amazing open-source project. It has provided many people with countless hours of high quality entertainment. At the same time many contributors strive to make it better, more inclusive and more enjoyable for more people. That is why we translators do our best to localize RA into any and all languages we can!

Unfortunately, some translation efforts have been stagnating for some time, so we would like to ask you for help: If you would like to contribute to localizing RetroArch into your language, and make this app even more amazing, please consider joining us at Crowdin!

More translators for any language would be great, but languages in dire need of some include:

– Arabic
– Asturian
– Chinese Traditional
– Czech
– Danish
– Dutch
– Esperanto
– Galician
– Greek
– Hebrew
– Hungarian
– Indonesian
– Persian
– European Portuguese
– Slovak
– Swedish
– Ukrainian
– Vietnamese
– Welsh

And if you can’t find your language on Crowdin, just notify us right over at the #retroarch-translations channel of the libretro Discord and we’ll see if it can be added.

We have prepared a written tutorial for all of you who want to get started.

If you have any questions, just hop on over to the #retroarch-translations channel and we’ll gladly help you out!

Hope to see you there!

RetroArch 1.9.13 release!

Libretro Team


RetroArch 1.9.13 has just been released.

Grab it here.

If you’d like to learn more about upcoming releases, please consult our roadmap here.

UPDATE (11/11/2021): A ninjafix release has been pushed. See our blog post 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. 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!

Highlights

Project IO continues

Project IO continues as we try to abstract all file I/O in libretro cores and RetroArch to meet the Google Play Store’s new policies. Android 11/12 requires the use of the Storage Access Framework for file I/O, as libc stdio access is being restricted as much as possible.

One of the beneficial side effects of Project IO is that in going over each core, we find out all sorts of long standing issues along the way, and we try to improve the cores along the way. So it serves as a much needed quality control check as well.

No RetroArch 1.9.13 for Google Play Store for now

Do not expect frequent updates to the Google Play Store version until further notice for now. This is because of the new Play Store requirements (as explained bove in the Project IO section). Basically what it comes down to is that despite our hardest work and effort, we have missed the deadline, and so any new APK that is pushed to Google Play is likely to be rejected until the minimum SDK Level (30) and SAF is being used. We are trying to work as fast as we can to get to that stage. A realistic target is possibly two weeks from now, but we’d rather not make promises and see how far we can get by that point. In the meantime, downloading it from our site (the non-Google Play Store version), the Amazon App Store, or Huawei AppGallery or all valid alternatives that should receive an update.

Automatic Frame Delay

After introducing unique innovations like runahead in the past, RetroArch continues to innovate once more and remains at the forefront of latency reduction: introducing automatic frame delay! Read all about it in our separate article here.

The aim of this option is to lessen the burden of creating core-specific and also game-specific overrides for Frame Delay, and instead go for “set it and forget it”. With 0 value, the starting point will be half frame time.

It is fairly simple and it is based on frame time averaging with a few different thresholds which filter out false positives and provide quick stabilization with bigger steps depending on the need.

It only goes down, it is temporary, and it will reset on core unload and on SET_SYSTEM_AV_INFO. The necessary values are shown in video statistics and all actions are logged in info level.

Some notes by the author:
* For Windows users – use the XAudio driver for now, WASAPI and DirectSound does not lead to reliable results with Auto Frame Delay for now.
* Early polling could behave better with frame delay. Try setting Polling Behavior from ‘Late’ to ‘Early’ and see if you prefer it that way. Note that that polling setting needs (restart) info with it, since it does not properly refresh in realtime. If it is anything but Late at startup, putting it to Late will be always one frame behind.

‘All Users Control The Menu’ option is back

A much requested feature by WiiU users is back again! This allows all the connected gamepad devices to control the menu simultaneously. It is enabled by default for WiiU and disabled for all other devices.

NOTE: Only player 1 can toggle the menu. This is a limitation of the current input system. But any set Menu Toggle Controller Combo will work fine for all users, so it is probably acceptable for now.

Initialise ‘Explore’ menu on a background thread

Before, accessing the Explore menu would freeze the user interface for up to several seconds (depending on host hardware performance) while playlists and databases are scanned.

1.9.13 just pushes the Explore menu initialisation onto a background thread, so the UI remains responsive while the various processing occurs. (Note that the host platform must of course have threading support – if not, Explore menu initialisation will remain on the main thread)

RetroAchievements – Replace co-routines with tasks

Not important much to endusers but still worthy of a mention to people familiar with the codebase. Replaces the single long-running load task for RetroAchievements with several smaller tasks (which are threaded).

This also eliminates the coroutine code as that was only being used to yield the long-running load task – there wasn’t actually anything else to be coroutine with.

Subtasks (i.e. 1a/1b) are queued together and can be executed in parallel. RetroArch’s task system only has one task thread, but the HTTP task does sort of interleave the server requests so they are more-or-less executed at the same time.

Core improvements

As mentioned before, as part of Project IO, we are going over every core and performing some basic quality control checks. This already resulted in numerous Quality of Life enhancements to cores. Not all of the improvements listed below can be attributed to Project IO, but it’s fair to estimate over 90% of them are.

mGBA

Description: mGBA is a Game Boy Advance emulator

Fixed audio pacing – no more crackles and bad frame pacing

GBA content ran with the mGBA core was sometimes subject to crackling audio and intermittent bad frame pacing (particularly when using low frontend audio latency settings).

It turns out that the core was handling audio suboptimally in the libretro layer. At the set audio sample rate, the frontend expects between 548 and 549 audio samples per frame – but the AVStream audio callback reads and sends exactly 512 samples. This means that the audio callback becomes desynchronised with retro_run() – sometimes 512 samples will get sent to the frontend for the current frame, sometimes 1024 as the core either falls behind or overcompensates. As a result, when the frontend tries to synchronise on audio, jitter can occur – and if the frontend audio buffer is small (when using low latency values), it can sometimes run dry or reach capacity, causing crackling.

Our changes modifies audio handling in the libretro layer such that the correct expected number of samples is sent to the frontend in proper synchronisation with retro_run(). With this change we no longer experience cracking audio in GBA games, and the 240p test suit demonstrates smooth scrolling.

Note that the changes here only affect GBA content. GB/GBC emulation produces irregular audio sample pacing that is not consistent with the set sample rate, and so I am unsure how best to handle it. The existing AVStream audio callback and fixed buffer size of 512 is therefore maintained for GB/GBC content (since it already seems to produce acceptable results in most cases)

Miscellaneous

While working on the above, we noticed that the audio produced by this core is somewhat ‘harsh’ sounding. We have added an optional (fast) low pass audio filter (with associated strength setting), which softens the generated output to a more comfortable level.

Since we had to modify the core options, we also took this opportunity to update the options to v2 format, with category support.

LRMAME

Description: This is the mainline MAME core based on current sourcecode

Update to 0.237

We have updated the LRMAME core to version 0.237.

1 frame of input lag removed from core

In addition, we are happy to report that a longstanding issue with this core has been resolved. There was previously 1 additional frame of input latency in this core. This has thankfully been shaved off now.

gpSP

Description: This is a Game Boy Advance emulator

x86 32bit/64bit dynamic recompilers

gpSP now has a dynamic recompiler for x86 x64 architecture processors! Now both 32bit and 64bit CPUs have a working dynamic recompiler.

This is now hands down the fastest Game Boy Advance emulator in existence on x86 x64 platforms, outside or inside of libretro/RetroArch. We have benchmarked it ourselves – on an i9 10900KF, we get a regular reading of 2270/2280 fps in fastforward mode with Super Mario Advance 2. This makes it even faster than QuickNES, an 8bit Nintendo Entertainment System emulator. It is a little bit slower than Gambatte (still one of the kings in terms of performant cores) at ~2300fps, but it bears reminding that Gambatte is only targeting 8bit Game Boy consoles as opposed to the 32bit Game Boy Advance.

With Advance Wars, we can get even crazier readings like anywhere from ~4000 to ~5000fps in windowed mode.

Suffice to say, this kind of performance before was simply unheard of for a GBA emulator. Suffice to say, if you were still hurting for performance with a Game Boy Advance emulator before (on whatever ghetto rig you have repurposed), give this a try!

prBoom

Description: This is a Doom/Doom 2/Ultimate Doom/Final Doom game engine core.

In addition to this core now using the VFS for file I/O, we also improved the following listed below.

Fix core options version detection

On recent versions of RetroArch the core options are currently falling back to v0 format (missing sublabels) due to a trivial ‘supported version check’ error in libretro_core_options.h. We fixed the issue.

Fix memory leaks + prevent potential segfault when saving/loading games

We tried fixing every memory leak that we could find in the core.

It also works around a nasty bug in the code for saving/loading games, where an array index can easily go out of bounds.

Note that we had to stub a certain deinit out for the Windows build, the z_zone memory management seems to be pretty hairy on Windows and we unfortunately haven’t found a clean way to fix that yet. However, we don’t expect this to be a big issue on Windows regardless since it’s a dynamically linked core that gets deallocated after unloading anyway. Most of the leaks on the statically linked consoles should be all gone, and that is what ultimately counts at the end of the day.

TyrQuake

Description: This is a Quake 1 game engine core.

In addition to this core now using the VFS for file I/O, we also improved the following listed below.

Fix startup crash on x64 systems

The core would segfault under some circumstances when running the shareware version of Quake on Windows.

It turns out that the code makes a number of assumptions about the width of certain data types when casting pointers, which are not true on a number of platforms. On 64bit Windows this can cause pointer addresses to be determined incorrectly – leading to chaos.

We fixed the issue by using standard fixed-width types for the affected pointer casts. It also cleans up some other related compiler warnings.

Clean up file path handling + fix segfault when loading content from ‘non-standard’ directories

Before, the core would segfault on certain platforms when loading PAK files from non-standard directories (anything other than id1, quoth, hipnotic, rogue) due to illegal usage of strncpy(). This can be observed most easily by attempting to run the shareware version of Quake from RetroArch’s online content downloader.

We fixed this issue, and also cleaned up all file path handling in libretro.c (using libretro-common routines). A number of libretro-common files have also been updated to the latest version.

Fixed memory leaks

We fixed three sources of memory leaks in the core:

* A relatively minor one related to loading PAK files (the file handle was always left open)
* Two serious ones in the sprite handling code, which may potentially trigger multiple times per frame (and which were likely to cause crashes on RAM limited platforms…)

Miscellaneous core improvements

We have been spending time improving fMSX (MSX emulator core), PX68K (X68K emulator core), and Frodo (Commodore 64 emulator core), but are not quite done yet. We will probably spend some time detailing the changes to these cores by the time the next release comes along (two weeks from now).

For WiiU users: Frodo has been added to the WiiU build.

  • Beetle PSX: Add static crop behavior for “Crop Overscan” alongside dynamic
  • Beetle PSX: Set game specific tweak to get Monkey Hero running past the title screen
  • FBNeo: Numerous updates – see below:
  • FBNeo: CPS1 – fix Strider palette fades
  • FBNeo: CPS1 – Stars: simplify/fix
  • FBNeo: CPS2 – added Super Street Fighter II: The New Challengers Super 2 (bootleg, USA 930911)
  • FBNeo: CPS2 – Corrected some overdumps for Alien Vs Predator [Guru]
  • FBNeo: Sync FB Neo with MAME 0.237
  • FBNeo: Spectrum updates from gab75
  • FBneo: Mega Drive updates from gab75
  • FBNeo: NES updates from gab75 – also add Goemon 2 Translation (English)
  • FBNeo: Fix Vigilante breakage
  • FBNeo: M90 – Hiscore support
  • FBNeo: PC Engine – Add sprite limit override DIP
  • FBNeo: PC Engine – Fix timing, arrange render pipeline, scale windowing for Supergrafx
  • FBNeo: Supergrafx – Dai Makai – perfect background scrolling fix
  • FBNeo: SNK – Fix Psychos DIPs
  • FBNeo: Colecovision – Fix v-linecount (glitch in Frogger)
  • FBNeo: Pacman – added Buccaneer (set 2) [Jeremy Locke, Cam]
  • FBNeo: d_seta.cpp: add dumps for plds in blandia set, and info for undumped plds
  • FBNeo: neogeo: add “The King of Fighters ’98 (Ratio hack)”
  • FBNeo: d_cps2.cpp: add Street Fighter Zero 2 Alpha (Asia 960805) [Genaro Rodarte]
  • FBNeo: New WORKING clone – Floritas (Multivideo Spanish Moon Cresta bootleg) [Retromaniacs]
  • FBNeo: Renamed ‘spcdraga’ as ‘floritas’
  • FBNeo: Add ‘floritasm’ and rename ‘spcdraga’ as ‘floritas’
  • FBNeo: Homogenized all “bootleg on Galaxian hardware” descriptions
  • FBNeo: Now there’s only one “Space Dragon” set
  • Frodo: Added WiiU build
  • Gambatte: Fix loading of custom palettes with CRLF line terminators
  • Genesis Plus GX Wide: Fix specific Plane B scrolling bug – This bug occurred when HSRAM values for Plane B were `>= 0x10000 – config.h40_extra_columns * 4` (e.g., `0xFFD8` when h40_extra_columns = 10) because of a bit carry into the upper 16-bit word of `xscroll`.
  • Kronos: Latest updates
  • MAME2003 Plus: Improve sound tempo for Dolmen and Twin Action – some sound niggles a constant crackling noise still remain
  • MAME2003 Plus: Use control name before universal default – uses the specific control name before filling with our universal defaults. Also update DAT.
  • MAME2003 Plus: Support a couple more Afega games – these just hang off the standard NMK16 code so can be added easy enough to nmk16.c rather than afega.c which would be more complicated
  • MAME2003 Plus: New gfx scrolling routine for Twin Action
  • MAME2003 Plus: Speed up macro search – refine search to look for player specific joycodes.
  • MAME2003 Plus: Add Amlogic S812 platform + cleanup unused vars in Makefile
  • PCSX2: Numerous updates – see below:
  • PCSX2: GS: Don’t propagate 24bit textures on download
  • PCSX2: GS: Properly loop when reading 32bit CLUT from offset
  • PCSX2: GS: Fix up CLUT offset handling in 32bit I8 mode
  • PCSX2: GameDB: Add gamefixes for Ruff Trigger
  • PCSX2: GameDB: Port Iridium Runners patch, update fixes
  • PCSX2: GameDB: Patch rounding problem in Playmobil Hype The Time Quest
  • PCSX2: GameDB: Sports (RTL)
  • PCSX2: GameDB: Katamari Games
  • PCSX2: GameDB: add VU clamping to ‘Enthusia Professional Racing’
  • PCSX2: GameDB: fix serial for ‘Panzer Elite Action – Fields of Glory’
  • PCSX2: GameDB: add EE clamping to ‘Max Payne 2 – The Fall of Max Payne’
  • PCSX2: GameDB: add VU clamping to ‘Battle Engine Aquila’
  • PCSX2: GS-hw: Don’t write clamped depth test value to depth buffer when ZMSK is enabled
  • PCSX2: GameDB :add VU clamping to Monster Rancher 3
  • PCSX2: GS-hw: Add Slam Tennis to automatic mipmapping.
  • PCSX2: EE: Cyclerate > 1 caused some cycles to be lost
  • PCSX2: GS-fx/glsl: Get rid of PS_ATST 0 condition. It does nothing so no need to have it in shader.
  • PCSX2: SIF: Kind of revert a SIF timing change made a while back to fix Parappa the Rapper 2
  • PCSX2: COP2: Fix reg allocation issue. Really fixes Devil May Cry which was a bug hidden by clamping hidden by a bug, yeah i think that covers it all…
  • Yabause: Fix pixel format on android

Changelog

1.9.13

  • CHEEVOS/MSVC2010: Add Cheevos support
  • CRT/SWITCHRES: Fixes some issue where scaling is incorrect in some video modes for CRT output.
  • FRAMEDELAY: Add ‘Automatic Frame Delay’ option
  • INPUT: Add ‘All users control the menu’ setting – any gamepad can control the menu when this is enabled. Only limitation right now is that only player 1 can toggle the menu, but any set Menu Toggle Controller Combo will work fine for all users, so this should be acceptable for now
  • INPUT/UDEV: Fix Dolphin bar and safeguard against not adding devices with no mouse or touch buttons detected
  • NETPLAY/CLI: -C/–connect commandline fix
  • NETPLAY: Other improvements
  • NETPLAY: Remove forced disconnection on unknown netplay command – will be backwards compatible with any version that removed this disconnect. instead of disconnecting, we just read the data and ignore, like most network implementations do
  • TASKS/CHEEVOS: Replace coroutines with tasks/thread
  • TASKS/DATABASE/EXPLORE: Initialise ‘Explore’ menu on a background thread – no more stall when hovering over the Explore tab

RetroArch 1.9.13 – Automatic Frame Delay

Libretro Team

Article written by Ryunam

RetroArch 1.9.13 introduces a new option called “Automatic Frame Delay”. It has been added to the Latency sub-menu (found under Settings -> Latency).

This new feature provides an effective way to avoid having to configure a specific value for the “Frame Delay” option for each and every core and individual piece of content that you may want to run, by automatically tuning down its strength based on your system performance.
This is yet another contribution that empowers our long-standing efforts in reducing input latency to the lowest extent possible. We feel this new addition also gives us a good opportunity to delve further into the inner workings behind the concept of “Frame Delay” and briefly explain what purpose this functionality serves and how we generally advise our users to apply it.

What is “Frame Delay”?

The setting known as “Frame Delay” has actually existed for some time in RetroArch. However, due to its nature and the complexity of its effect, it has always required a level of strictly manual adjustment and finetuning on the user side.

To best describe the underlying mechanism, let us briefly touch upon the timing of when a new frame is produced (including when the inputs are sampled) and then displayed on-screen.

The way frames are rendered and then displayed on video can be best understood by considering this sequence:
• each frame has a set duration, namely a “frame time” or “frame period” as it is usually called, which on a 60hz screen and in ideal circumstances corresponds to a length of 16.7 milliseconds on average;
• as per the picture shown above, once the first frame is shown the next frame starts being prepared “behind the scenes”. This rendering process includes the moment the inputs are polled and it all happens within the allotted frame period;
• in typical situations the rendering process of the next frame is finished some time before the given frame period is over;
• this results in the next frame essentially “stalling”, being left in a suspended state for a few more milliseconds than necessary, until the frame period is properly finished;
• only at that point the newly created frame is presented on-screen.

While the process described here is normal and does not usually yield a considerable impact on latency, the fact that the next frame has to be put “on hold” and wait a certain amount of time from the moment it finishes rendering until the end of the frame period does in fact contribute to the combined responsiveness of the inputs.

This is where “Frame Delay” comes into play.

Depending on the value set for the “Frame Delay” option, the creation of the new frame including the input polling can be postponed by a certain number of milliseconds, until the last moment that is realistically viable.

Doing this requires some additional CPU processing power depending on the chosen amount of delay, but it also helps decrease the number of milliseconds that the new frame – which has been prepared and is ready to be presented on video – has to remain on hold. As a consequence, adjusting the “Frame Delay” setting can offer a slight – albeit measurable – improvement to the perceived input latency.

The “Automatic Frame Delay” setting

The problem with the “Frame Delay” setting has been traditionally that the many cores and types of content available, as one may expect, are vastly different and often have varying degrees of system and CPU requirements.

Users have had to constantly tweak the “Frame Delay” values for each specific situation, often resorting to set either per-core or per-content overrides, so that the benefits of the latency reduction could be had without stumbling on framerate drops, stutter, audio crackling and all sorts of other issues.

With the introduction of the “Automatic Frame Delay” toggle, the use of this functionality becomes simpler: the amount of delay time for the rendering of the new frame will scale down automatically, if the system detects any framerate fluctuation/drop, until it reaches a value that allows your gameplay to remain stable while still retaining a certain extent of latency reduction.
Here is a quick rundown of the different ways that you can enable and apply this setting, based on your preference:

• if you set “Frame Delay” to 0 and “Automatic Frame Delay” to ON, the starting point of the delay that is applied to the new frame will be half your “frame period”. For instance, on a typical 60hz screen with a frame time of 16.7 ms, the initial value applied will be “8”, as in 8 milliseconds of delay. Afterwards, if drops or hiccups are detected in the video performance, this value will be reduced dynamically until it reaches a stable point;

• if you set “Frame Delay” to any value higher than 0 and “Automatic Frame Delay” to ON, the starting point will be the delay value that was manually set. For instance, if “Frame Delay” is set to 10, the initial amount of delay for the processing of the new frame will be 10ms. Then, it will be adjusted downwards in case any framerate drop is detected;

• if you set “Frame Delay” to any value higher than 0 and “Automatic Frame Delay” to OFF, the automated scaling of the frame delay setting will be disabled. The amount of delay applied to the rendering of the new frame will be exactly the one chosen and will not change or decrease during gameplay at all;

• if you set “Frame Delay” to 0 and “Automatic Frame Delay” to OFF, no amount of delay will be applied to the rendering of the new frame. Frame Delay will be disabled entirely.

Conclusion

While the tangible effects of “Frame Delay” on the total combined latency might be small compared to other implementations such as Runahead, this setting has the advantage of being applicable to all cores and content, albeit to varying degrees.

The added convenience of having “Frame Delay” scale down automatically is yet another asset in making sure that you can run your content with the lowest latency possible.

Hopefully this new toggle allows a greater ease of use of this particular option for our users. We definitely encourage experimenting with it and testing it with the wide array of cores available for the libretro platform!

RetroArch 1.9.12 released!

Libretro Team


RetroArch 1.9.12 has just been released.

Grab it here.

If you’d like to learn more about upcoming releases, please consult our roadmap 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. 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!

Highlights

Steam


New cores are on the verge of being approved on Steam. First out of the gates is Picodrive, a Sega Genesis/Master System/Sega CD/32X emulator. You can grab that for RetroArch right now here.

We’d also like to remind users that are still using the RetroArch Play Test version on Steam to please migrate over to the mainline Steam release now and to stop using it. The Play Test version is outdated and won’t really be updated anymore after this point.

Miyoo – Pocket Go, PowKiddy Q90-V90 and New BittBoy – Over 28 cores now

For version 1.9.11, we added support for Miyoo devices, such as the Pocket GO, PowKiddy Q90-V90 and New BitBoy. Back then, we only had one or two cores available.

Version 1.9.12 now comes with a whopping 28 cores – quite the improvement over 1.9.11.

List of all cores so far –

  • 81
  • CAP32
  • fMSX
  • FUSE
  • Gambatte
  • Genesis Plus GX
  • GW
  • Handy
  • LRMAME2003
  • LRMAME2003 Plus
  • Mednafen PCE Fast
  • Mednafen Wswan
  • mGBA
  • NXEngine
  • O2EM
  • Picodrive
  • PokeMini
  • Potator
  • PrBoom
  • Prosystem
  • QuickNES
  • RACE
  • Retro8
  • ScummVM
  • SMS Plus
  • Stella 2014
  • Theodore
  • Vecx

NOTE: We are not affiliated or have any association with the companies behind these devices.

HID subsystem unification – improvements/bugfixes

1.9.11 added a new unified HID subsystem that works on both Mac and WiiU.

Version 1.9.12 features several crucial bugfixes and additions that were plaguing the initial implementation in 1.9.11. See the CHANGELOG at the end of this blog post for more details.

Increased backwards compatibility for macOS cores

Since the migration to our new infrastructure, the minimum OS requirements for macOS cores unintentionally went up. We have since taken steps to address this.

Here are the current minimum OS requirements:

  • 2048: 10.9
  • 81: 10.9
  • atari800: 10.9
  • bk: 10.1
  • blastem: 10.9
  • bluemsx: 10.9
  • bsnes2014_accuracy: 10.9
  • bsnes2014_balanced: 10.9
  • bsnes2014_performance: 10.9
  • bsnes_cplusplus98: 10.9
  • bsnes_hd_beta: 10.9
  • bsnes: 10.9
  • bsnes_mercury_accuracy: 10.9
  • bsnes_mercury_balanced: 10.9
  • bsnes_mercury_performance: 10.9
  • cannonball: 10.9
  • cap32: 10.9
  • craft: 10.7
  • crocods: 10.9
  • desmume: 10.7
  • dinothawr: 10.8
  • dosbox_core: 10.9
  • dosbox_pure: 10.9
  • dosbox_svn: 10.9
  • duckstation: 10.15
  • easyrpg: 10.9
  • ecwolf: 10.9
  • fbalpha2012_cps1: 10.9
  • fbalpha2012_cps2: 10.9
  • fbalpha2012_cps3: 10.9
  • fbalpha2012: 10.9
  • fbalpha2012_neogeo: 10.7
  • fbneo: 10.9
  • fceumm: 10.9
  • fixgb: 10.9
  • flycast: 10.9
  • fmsx: 10.9
  • freechaf: 10.9
  • freeintv: 10.9
  • frodo: 10.9
  • fuse: 10.9
  • gambatte: 10.9
  • gearboy: 10.9
  • gearcoleco: 10.9
  • gearsystem: 10.9
  • genesis_plus_gx: 10.9
  • genesis_plus_gx_wide: 10.9
  • gme: 10.9
  • gpsp: 10.1
  • gw: 10.9
  • handy: 10.9
  • hatari: 10.9
  • lowresnx: 10.9
  • lutro: 10.9
  • mame2000: 10.9
  • mame2003: 10.9
  • mame2003_plus: 10.9
  • mame2010: 10.9
  • mame: 10.9
  • mednafen_gba: 10.9
  • mednafen_lynx: 10.9
  • mednafen_ngp: 10.9
  • mednafen_pce_fast: 10.7
  • mednafen_pce: 10.7
  • mednafen_pcfx: 10.9
  • mednafen_psx: 10.9
  • mednafen_saturn: 10.9
  • mednafen_snes: 10.9
  • mednafen_supergrafx: 10.9
  • mednafen_vb: 10.9
  • mednafen_wswan: 10.7
  • melonds: 10.9
  • mesen-s: 10.9
  • mesen: 10.9
  • mgba: 10.9
  • mrboom: 10.9
  • mu: 10.9
  • nekop2: 10.9
  • neocd: 10.9
  • nestopia: 10.9
  • np2kai: 10.7
  • nxengine: 10.9
  • o2em: 10.9
  • oberon: 10.9
  • opera: 10.9
  • parallel_n64: 10.7
  • pcsx_rearmed: 10.9
  • picodrive: 10.6
  • play: 10.14
  • pocketcdg: 10.9
  • pokemini: 10.9
  • potator: 10.9
  • ppsspp: 10.9
  • prboom: 10.9
  • prosystem: 10.9
  • puae: 10.6
  • px68k: 10.7
  • quasi88: 10.9
  • quicknes: 10.9
  • race: 10.9
  • reminiscence: 10.9
  • retro8: 10.9
  • sameboy: 10.9
  • scummvm: 10.9
  • smsplus: 10.7
  • snes9x2002: 10.9
  • snes9x2005: 10.9
  • snes9x2005_plus: 10.9
  • snes9x2010: 10.9
  • snes9x: 10.9
  • squirreljme: 10.9
  • stella2014: 10.7
  • stella: 10.9
  • tgbdual: 10.7
  • theodore: 10.7
  • thepowdertoy: 10.15
  • tic80: 10.15
  • tyrquake: 10.9
  • uzem: 10.9
  • vba_next: 10.9
  • vbam: 10.9
  • vecx: 10.9
  • vemulator: 10.9
  • vice_x128: 10.9
  • vice_x64: 10.9
  • vice_x64sc: 10.9
  • vice_xcbm2: 10.9
  • vice_xcbm5x0: 10.9
  • vice_xpet: 10.9
  • vice_xplus4: 10.9
  • vice_xscpu64: 10.9
  • vice_xvic: 10.9
  • virtualjaguar: 10.9
  • vitaquake2: 10.9
  • x1: 10.9
  • xrick: 10.9
  • yabause: 10.9

We intend to drive down the requirements even lower in the coming months. For C++-based cores, the lowest we can go is 10.9. Going lower would require installing an older SDK version. For C-based cores, the lowest we can go is 10.4 for Intel-based architectures.

Project IO – Continued

You’ve read in our previous blog post that we were working on a long-term project to wrap/abstract all file system I/O in cores, and also correct and improve cores along the way. This work has continued for version 1.9.12, and we are happy to report that various cores have been improved substantially as a result.

Below are all the cores we managed to cover so far. The ones listed in bold are the new cores we have covered since 1.9.11.

Project IO – FCEUmm improvements

We replaced all direct file access in the core with VFS routines (libretro/RetroArch#12949)

In addition, it turned out that this core had been violating the libretro API for some time by setting need_fullpath = false but then requiring the content fullpath to detect the region of iNES v1.0 ROMs. This PR fixes the issue by setting need_fullpath = true by default, but then lifting this restriction for frontends that support the RETRO_ENVIRONMENT_SET_CONTENT_INFO_OVERRIDE environment callback (which allows a valid content name to be extracted even when using a frontend-provided data buffer)

Built-in Game Genie support

FCEUmm has long supported emulation of the Game Genie cartridge add-on, but this is currently unavailable in the libretro core. 1.9.12 wires up said functionality:

A new core option Game Genie Add-On (Restart) has been added (disabled by default)
In order for the option to apply, the Game Genie ROM file named gamegenie.nes must be present in the frontend system directory
Game Genie support is disabled for FDS and arcade content
Save states do not function (and are disabled) while the Game Genie boot screen is open
After enabling Game Genie Add-On (Restart), launching a game will cause the Game Genie boot screen to appear. Codes can be entered with the gamepad (as on real hardware): D-Pad to move, A to select, B to delete. For example:

Super Mario Bros.
YSAOPE + YEAOZA + YEAPYA Start on World 8

Why would we want this functionality, when the regular cheat interface is already available? Because:

* It provides an authentic experience
* It enables cheats when using frontends that don’t support the regular cheat interface
* All the code was already in place, and it was easy to enable 🙂

In addition, during the process of implementing this, the core’s OSD messaging code was overhauled and cleaned up. OSD warnings will be displayed when appropriate if the Game Genie ROM file is missing, and also if the FDS bios is missing. OSD message durations have been shortened a little, and the core makes use of the extended messaging interface when available.

Color palette switching

At present it is difficult to compare the core’s Color Palette options, because these can only be set via the quick menu. 1.9.12 adds the ability to switch to the next/previous colour palette by holding RetroPad L2 and pressing D-Pad Left/Right while content is running.

Memory leaks fixed

Numerous memory leaks have been fixed while going over this core. This should benefit in particular all the statically linked platforms, such as game consoles.

Project IO – SameBoy improvements

1.9.12 makes the following changes to the core:

Direct file access has been replaced with VFS routines (libretro build only) (Cores with straight stdio file I/O RetroArch#12949)

The core now sets need_fullpath = false, such that content is loaded from the frontend-supplied memory buffer. (Cores that should be turned into need_fullpath = false)

Since the core no longer receives a content path, automatic ROM type detection cannot be based on file extension (.gb, .gbc). We now therefore inspect the ROM header, which means we can also distinguish SGB-enhanced content. As a result, the System – Emulated Model core option has been modified such that the Auto settings are:

Auto Detect DMG/CGB (default): Emulated hardware will be set to either Game Boy or Game Boy Color depending upon the ROM.
Auto Detect DMG/SGB/CGB: Emulated hardware will be set to either Game Boy, Super Game Boy or Game Boy Color depending upon the ROM.
A new Auto Detected SGB Model has also been added, to enable selection of which type of SGB hardware to emulate when content is detected as being SGB-enhanced.

Since it was necessary to edit the core options anyway, these have been updated to v2 and option categories have been added.
Note that all changes here (apart from two .gitignore additions) are limited to the libretro directory – no ’emulator’ code has been modified.

Fixes issue #58 – ‘Better Auto System Model Support #58’
Fixes issue #52 (since the core no longer loads ROMs directly) – ‘Can’t load ROM files with special characters in filename’

PCSX ReARMed – Improvements

Lots of improvements have been made to PCSX ReARMEd courtesy of gameblabla –

  • Literals are deduplicated, so there’s no guarantee they will be stored next to each other, even if they’re written sequentially. verify_dirty and get_bounds must use the offsets on each instruction, instead of assuming values are stored sequentially. According to neonloop, this fixes a dynarec crash in FF7 on ARMv5 platforms like the F1C200S as used in the TrimUi handheld. Given that the old3DS is ARMv6, it may also possibly fix some crashes there as well.
  • GTE stalls/timings – This is to fix an issue with Battle Arena Toshinden 1 and Zero Divide going too fast. To test the GTE fix with Battle Arena Toshinden : Boot the game and go to “Vs.computer” at the titlescreen. Then, choose any character except rungo and select Rungo for the computer.
    Before, the game would go too fast. Now, it will run at the correct speed. (well very close, PCSX rearmed’s clock counting is still kinda finicky). The fix in question was inspired by a similar fix from PCSX-Revolution. Might also fix NBA Jam Extreme.
  • Fix for Armored Core misdetecting a Link cable being detected -fFor some reason, the game would detect that a link cable is plugged in and disables the local multiplayer as a result.
  • Various CDROM fixes from Swanstation and Mednafen. These fixes aim to address the inaccuracies of some CDROM commands and make it on par with nocash’s doc and mednafen. So far, it mostly fixes some delay issues in the Simple 1500 sound novel game as well as F1 2000 (which is notoriously time sensitive).
  • Merge several fixes from PCSX Redux and adjust delay for SetLocPending. There’s a game, PoPoLoCrois Monogatari II, that unfortunately locks up during the intro screen.
    I should have known that code was wrong as Mednafen did not have anything like that in their code either, hence the confusion.Their fix however still don’t include the Driver fix so the game would still crash if we don’t have the “+ Seektime”.
    To be honest, i’m not sure why the PCSX Reloaded team did it this way…
    In any case, i adjusted it so it doesn’t mess up the audio for Driver’s titlescreen and doesn’t crash in Worms Pinball either.
    Seems like setting it to 100000 was not enough for that game.

    I noticed the fastword and FastBackward were not being used in any way.
    Looked at Mednafen and all they do is just adjust the cursector
    and make sure that fastword & backword trigger the AUTO_REPORT code so i did the latter.

  • CDROM: Rename Reset+Init commands, fix “This is Football 2” lockup
  • CDROM: Ignore sectors with channel number 255 – This was tested on “Blue’s Clues : Blue’s Big Musical” and it fixed the missing audio there.
    Taxi 2 is also said to be affected by this.
  • ICache emulation (Interpreter) from PCSX redux. Known games to be affected by the lack of or improper ICache emulation : Formula F1 99, Formula F1 2000 (EA), Formula One Champion Season 2000
    Formula One Arcade, Formula F1 2001 (Confirmed to be fixed), Buster Bros. Collection, ISS Pro 98
  • Dare to set MDEC_BIAS to 10 – This based on an original fix by dmitrysmagin in PCSX4ALL. “This fixes graphic artifacts during cinematics in Vandal Hearts and R-Types, other games seem to be unaffected. (?)”
  • GTE: Fix gteH division and sign extension (from PCSX4ALL) – Original comment by senquack :
    “gteH register is u16, not s16. DIVIDE macro/func assumed it was
    s16 for some reason. Behavior now matches Mednafen.” I also put in there the “GTE_USE_NATIVE_DIVIDE” stuff but currently unless manually enabled, it’s not used.
    You may wish to use this on some low end platforms but that’s up to you.
  • [SPU] Emulate SPUSTAT[5:0] as a mirror of SPUCNT[5:0] – I have tested the fix against Loonies 8192 (a PSn00bSDK made homebrew game) and it no longer locks up during loading. This affects all games and demos that uses PSn00bSDK. (I’ve been told it’s unlikely this will affect games that uses the official SDK)
  • Implement fix from Mednafen for Fantastic Pinball Kyuutenkai – this also fixes ‘Multi Track games crash on .CHD’.
  • CDROM timing changes – fixes Crash Team Racing’s intro music cutting off too soon – FF8 Lunar Cry FMV freeze (Disc 3) – Worms Pinball not booting – Xenogears (Deus fight)
  • Fix CD Volume issue in Star Wars Dark Forces – CD Volume is 16-bits signed, not unsigned.
    Otherwise in Star Wars – Dark Forces : if you lower the music volume slider all the way down, the volume will wrap around and instead be set at the highest volume.

Ozone – new color themes

Solarized Light theme for Ozone menu driver
Solarized Light theme for Ozone menu driver
Solarized Light theme for Ozone menu driver
Solarized Light theme for Ozone menu driver
Solarized Dark theme - Ozone
Solarized Dark theme – Ozone

Two new color themes got added – Solarized Light and Solarized Dark.

Libretro additions – Enable SRAM for contentless cores

Before, the saving/loading of SRAM data is disabled for contentless cores – which means that cores such as 2048 have to handle save data internally instead of utilising frontend-provided functionality.

1.9.12 simply disables this artificial and unnecessary restriction.

Changelog

1.9.12

  • 3DS: Ensure parallax barrier is disabled when ‘3DS Display Mode’ is ‘2D’
  • COMMAND: Command interface should work again
  • INPUT/HID: Rewrote the HID deregistration algorithm; it should no longer cause issues when dealing with multiple pads of the same HID/VID combo
  • INPUT/HID: Fix initialization bug that caused wiimotes to fail to register without an accessory attached
  • INPUT/HID: Fix Wiimote regression
  • INPUT/HID/MAC: Get Sony Sixaxis (DualShock 3) working on MacOS
  • INPUT/UDEV: Add extra abs check for dolphinbar
  • INPUT/UDEV: Add relative left mouse button when pointer device is not abs
  • INPUT/WAYLAND: Fix keyboard input on Wayland – fixes ‘Certain cores ignore user input’
  • NETPLAY: Improvements from Cthulhu
  • OPENDINGUX: Fix HAS_ANALOG/HAS_MENU_TOGGLE defines in sdl_dingux joypad driver
  • LIBRETRO: Enable SRAM for contentless cores
  • LIBRETRO: Add environment callback to get the rate retro_run is called – GET_THROTTLE_STATE and RETRO_THROTTLE_UNBLOCKED environment callback
  • LINUX: Update metadata manifest
  • MENU/OZONE: New themes – Solarized Light, Solarized Dark
  • WINDOWS/WIN9X: Fix non-ASCII text display in window title

RetroArch 1.9.11 released!

Libretro Team


RetroArch 1.9.11 has just been released.

Grab it here.

If you’d like to learn more about upcoming releases, please consult our roadmap here. The next version of Lakka (with an updated RetroArch 1.9.11 version) is scheduled to be released very soon!

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. 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!

Highlights

Steam information

In case you have missed our previous announcement, take the time to read this article.

TLDR – we switched over to the Soldier runtime for Steam Linux builds which should increase compatibility with various Linux distributions.

As for how things are progressing on Steam, we are currently waiting on new depots before we can add the next batch of core DLCs. Stay tuned!

Miyoo – Pocket Go, PowKiddy Q90-V90 and New BittBoy now supported

We now have an official build (dubbed Miyoo) for the cheap impulse purchase handheld consoles listed below:

  • Pocket Go
  • PowKiddy Q90-V90
  • New Bittboy

These are cheap, low-spec ARM handheld consoles powered by OpenDingux that can be bought for $50 or less. Currently we have only a few cores available in this official version, but expect us to expand the cores list significantly soon. And as a result of the initiative Project IO, expect cores to become more suitable for low-end devices like this and its ilk as well. We care very much about continuously improving our cores so that they become more suitable for the low-end spectrum of devices. And the nice thing about that is that this ends up benefiting the high-end devices as well.

NOTE: We are not affiliated or have any association with the companies behind these devices.

HID subsystem unification – WiiU Gamecube adapter now works on Mac

Previously, the WiiU and Mac ports used a completely different HID subsystem. This has now been unified, so that both WiiU and Mac use the same underlying system.

Thanks to this, Mac RetroArch gets some nice additions, such as Gamecube WiiU adapter support. It should also work on WiiU RetroArch itself. Currently it only works with the first gamepad in controller port 1.

Further, author gblues remarks: “I don’t have any of the devices in order to confirm, but I think the other HID devices (SNESUSB, HID-capable PS4 controllers, etc.) should start working.”.

NOTE: While the WiiU side has been tested, there might still be things that don’t work like they did before. Hopefully whatever issues are found can be patched up in subsequent versions.

RetroArch PS2 – Resolution switching support

1.9.11 provides the ability to change the resolution for RetroArch PS2. The approach used is based on how it was implemented in the past for the Wii.

We finally have 240p support for RetroArch PS2! 240p probably is recommended to play on CRT. However, 480p is recommended for HDTV (component cable is needed however for progressive scan).

Features:

  • Be able to change resolution on PS2 (it’s possible to use 240p and 288p modes now)
  • You can center the video content on the CRT screen (new settings option for Video Offset X/Y)

Instructions

You need an RGB SCART cable for 240p/288p video modes.
You need an AV component cable for 480p/576p. Be aware that 576p is only available for the latest PS2 console versions (SCPH-750XX and higher).

Project IO – Wrapping file I/O

We have put in an extraordinary amount of work into our core library and trying to update them one by one so that they no longer use direct file I/O where possible. We are of course nowhere near done with this yet, but along the way it has given us the opportunity to do quality control checks on cores, and fix issues where necessary. Think of it as a glorified quality control check if you will.

Here are the cores we managed to cover thus far:

As you can see considering this list and how many cores Libretro/RetroArch has in total, We are nowhere near done yet of course.

Why are we doing this? Both the UWP/Xbox port and the Android port require it. Direct file I/O is more and more beginning to get sidelined on these platforms due to ‘security concerns’. In order to achieve this, each core that needs to use disk I/O will need to go through libretro’s VFS layer (Virtual File System).

Along the way, we have investigated if certain cores are not better off doing away with file I/O altogether, and if the input file can just be passed to the core as a memory buffer. For some cores, we have done just that. Other issues we found in other cores were memory leaks (sometimes related to disk I/O), and we took the time to plug those leaks.

Other design considerations along the way involve a core writing to multiple config files – for the cores we maintain ourselves, we try to avoid this. Instead, settings should just be part of the core options instead. So to that end, we will be modifying cores like Prboom (the Doom engine core) so that it no longer writes an auxiliary prboom.cfg file inside the saves directory, but instead writes those values back to the core options. This is going to be a bit tricky since the Prboom core allows you to access and change the settings in-game with its built-in Setup menu. In order to accomplish being able to change core options on the fly programmatically, jdgleaver graciously implemented an extension to the libretro API that allows us to do this.

It might be worth mentioning what kind of approach we take to file I/O in a core.

  • If a core’s input files (read: ROM for an emulator core) can fit reasonably into memory without exhausting main RAM, we are always in favor of setting ‘need_fullpath = false’ for a core. This way, the frontend can pass the content to the core as a memory buffer. Advantages of this? soft-patching support covered by the frontend. Other advantages are not limited to but include: less memory copies (see the next point), better performance due to no disk I/O after initial load, etc.
  • In case the memory buffer can be flagged as ‘persistent’, it can even remove the need for additional memory buffer copies in the core. Meaning less RAM being used. We have found that we unfortunately cannot do this for every core, as in some cases, a core might still be writing to the memory buffer after initial setup/reading of the input file (think of memory patching). In such cases, the memory buffer is not really persistent, so the core itself still has to maintain its own memory buffer copy.
  • If we can avoid disk I/O in a core, we try to do it. There are multiple reasons for this. One is performance : disk I/O can be by far one of the biggest bottlenecks in your system, and its performance can be entirely variable and random depending on what storage device you’re using. The other one is because from the perspective of a core, we don’t want users to have to place specific config files in specific places in order to change settings. Ideally, as many settings as possible are just implemented through core options so that the user always knows that he only needs to edit this one file instead of several stray files. This is obviously the goal, and it might still be the exception to the rule, but we’ll keep going through cores and seeing what the status of it is in certain cores, and make suitable adjustments.
  • Disk I/O happening during runtime is rarely a good idea from a performance perspective. You run the risk of introducing micro stutters and/or other undesirable issues. We therefore try in libretro cores as much as possible to avoid direct file writing to log files or any other examples of direct disk I/O for the duration of a core. For instance – this is the reason why the frontend is in control of SRAM saving/loading in libretro since its inception. Games like Shiren The Wanderer on SNES would write to SRAM as a ‘scratchpad’ every single time you move or press a button in the game. If you were to write to disk for every single step you take, not only do you incur wear and tear on storage devices with a limited amount of max read/writes like SSDs, but you’re also creating performance issues due to disk I/O. Hence our reason for always being mindful of what gets written to disk or read from disk in general.
  • Another issue relating to the location of files on disk – for the cores that we self-maintain, we like to be able to not demand of the user that they need to place required asset files in specific locations, like the system dir. Of course this is unavoidable for things like BIOS files, but for certain assets that the emulator itself provides, an effort should be made to try to embed these resources into the core so that it’s not the user’s problem to have to place all these cores somewhere. This increases core portability and makes it so the only thing a user has to care about is just moving a core over to the core directory, maybe supplying a BIOS in the system dir, and he is done from that point on and off to the races.

Expect us to be going over more and more of the cores. The Google Play Store (and Android itself) is pretty much going full-force in sandboxing disk I/O, and Xbox UWP has its own issues when it comes to direct file I/O (apparently it copies files that use direct disk I/O over to a temporary dir first before touching them or reading them, which can get clogged up fast). So it’s important that a lot of the cores have been covered by the time 1.9.12 rolls out.

Project IO – Improvements to cores

Here is a small example of the kinds of improvements that have been made to various cores as a result of Project IO that users will be able to appreciate and notice:

  • FCEUmm – Fixed a bug where it would cause the core to fallback to core options with no sublabels.
  • Game Music Emu/GME – Content loading has been fixed. Also fixed – a segfault when an invalid content path is provided, a segfault when loading content successively. And a few of the more obvious memory leaks has been fixed (there remain many more in this core though)
  • Gambatte – Now has toggling between palettes by pressing the L/R buttons.
  • Handy – the BIOS has been made optional, previously it was required but was not actually used. EEPROM save files are now generated in the frontend save directory, instead of the content directory. All logging is now performed via the frontend logging callback, and audio processing to libretro has been made more efficient.
  • PocketCDG – A file handle leak has been fixed.
  • RACE – The loading of real BIOS files has been disabled. This never actually worked before (the bios path was not configured corectly), and the use of a real BIOS with RACE is strongly discouraged – the relevant code path is not properly tested, and there are known issues with games.
    A workaround for a rare segfault (buffer overflow) has been added (the underlying cause of the overflow remains unknown, but this at least prevents the core from crashing and seems to have no adverse side effects)
  • QuickNES – Now has toggling between palettes by pressing the L/R buttons.

Direct3D9 driver works again!

RetroArch’s Direct3D9 driver finally works again after a long period of downtime. This is important because of our commitment to old hardware. You will find that many GPUs on Windows might have either spotty OpenGL drivers or they have no OpenGL support beyond OpenGL 1.0/1.1 (hopelessly archaic, a spec dating back to the late ’90s). Your previous options when faced with a graphics card that either doesn’t support OpenGL 2.0 or Direct 3D 10/11 would have been SDL or OpenGL 1.0. Now there is a viable third option – Direct3D 9.

Just to temper expectations:

  • Right now there is no shader support yet. Hopefully later on we can get the Cg and HLSL backends to work.
  • Only RGUI is fully supported as a menu driver right now. The graphics are still not displaying properly when using MaterialUI, Ozone or XMB. So only use RGUI for now with the Direct3D9 driver.
  • It relies right now on Direct3DX for font rendering, which is deprecated. Hopefully we can get rid of this dependency later on.

Of course, if your GPU is more than capable, we’d highly encourage you instead to use Direct3D 10/11/12 drivers in RetroArch. Use Direct3D9 only as a last resort when your GPU absolutely does not support Direct3D 10 and/or later.

NOTE: It will be very unlikely Direct3D9 will get Slang shader support. Most likely it will be limited to the old-style Cg shader format (since HLSL on Direct3D9 is nearly equivalent to Cg). It is our hope that we will be able to reuse the same Cg shaders for both the Cg and HLSL backends, and that people will be able to switch inbetween the two backends. For now, the HLSL and Cg backends are non-functional until further notice.

It is worth mentioning that RetroArch supports a wide variety of Direct3D versions. There is a working driver for Direct3D 8, Direct3D 9, Direct3D 10, Direct3D 11, and Direct3D 12. We do this to cast a large wide net so that we can support as many older GPUs as possible without having to resort to non-hardware accelerated rendering. Direct3D 8 driver will be unlikely to ever get shader support because pixel shading was very much in its infancy back then. Direct3D 9 will likely get Cg/HLSL9 shader support. Direct 3D 10/11/12 meanwhile fully support the new modern slang shader format that other video drivers also use (such as OpenGL 3/Core, Vulkan, and Metal).

Changelog

1.9.11

  • ANDROID: New launcher logo – will fill the corners on the homescreen
  • D3D9: Driver works again (RGUI only and software rendered cores work, no shader support yet)
  • HID/MAC: WiiU GameCube Adapter now works
  • HID/WIIU: WiiU and general HID subsystem unified/merged
  • INPUT: Refactor menu toggle combo button logic to allow quit combo button
  • INPUT/UDEV: Add mouse relative check and set appropriately to fix issue
  • LIBNX/SWITCH: Splitted Joycon button mapping
  • LIBRETRO: Add environment callback to enable cores to notify the frontend that a core otion value has changed
  • MIYOO: Add initial port
  • OPENDINGUX/RG350: Enable tinyalsa for the RG350
  • PS2: Add ‘Change Resolution’ option
  • PS2: Add option to change video windows offsets
  • STEAM/LINUX: Move to new ‘soldier’ runtime
  • WAYLAND: Remove xdg-shell-v6 protocol
  • WINDOWS: Fix non-ASCII text display in window title
  • WINDOWS 11: Shows Windows 11 version name now (Information -> System Information)
  • UWP: Further improvements to WinRT VFS layer