Changing behavior of “gl” and “glcore” video drivers

What are they ?

“gl” and “glcore” are 2 video drivers available on desktop computer :

  • “gl” is an OpenGL 2.0+ driver, when used with a version above 3.0 it’s called OpenGL Compatibility and can support up to OpenGL 4.6, but some GPU drivers don’t have that OpenGL Compatibility mode.
  • “glcore” is an OpenGL 3.1+ driver, it’s also called OpenGL Core, it supports up to OpenGL 4.6.

OpenGL is one of graphics API that can be used to draw 3D with you GPU, it is the most widely supported by devices and emulators.

What changed ?

Until now, when launching a core with an OpenGL renderer, RetroArch would consider both “gl” and “glcore” video drivers as valid choices, meaning you could launch a core internally using OpenGL Compatibility with the “glcore” video driver, and a core internally using OpenGL Core with the “gl” video driver. It’s not possible anymore, now cores will try to force the video driver matching what they want. This change only concerns platforms with OpenGL Core support, meaning platforms like android and many others aren’t concerned. Here is a list of cores using OpenGL and how they will be affected.

The following cores will always try to force the “glcore” driver :

  • kronos
  • citra
  • beetle-psx-hw
  • mupen64plus_next (on linux)
  • melonDS

The following cores will always try to force the “gl” driver :

  • openlara
  • parallel-n64
  • yabasanshiro
  • mupen64plus_next (on windows)
  • boom3

The following cores are compatible with both (some of them might work better with a peculiar driver depending on your gpu though), so they’ll try to use your current driver :

  • duckstation
  • dolphin
  • ishiiruka
  • ppsspp
  • flycast
  • desmume

Why was this change needed ?

Maybe you are one of the lucky guys who didn’t encounter major issues with the previous behavior, but there are actually several reasons to change this :

  • some cores will glitch if the video driver doesn’t match the context they are requesting
  • cores will usually perform faster if you use the video driver they expect
  • OpenGL compatibility isn’t reliable for cores that require OpenGL versions above 3.0, because some GPU drivers don’t support this, so it’s safer to force OpenGL Core in those cases
  • to be honest, it makes more sense like this, it leverages user experience, and we shouldn’t ignore what is requested by the core

Should i change something on my setup ?

The first thing you should make sure, is that the setting “Allow cores to change video drivers” is turned on (that’s the default), as far as i know turning this setting off was used as a workaround for some of the issues fixed by those commits, so i don’t see a scenario anymore where it could be anything but harmful.

The second thing you should do, is update the cores mentioned above if you are using them, half of them were patched over the last few weeks, in preparation for those changes. Sadly our buildbot currently has troubles building some of those cores, so i recommend manually installing them from the newer builds available at https://github.com/hunterk/libretro_builds until the new buildbot is ready (for dolphin, you might have to install vc_redist from here).

The third thing you should do if those changes prevent a core from working on your setup, is to mention me (@barbudreadmon) on github or discord so that i can look into your issue.

Last but not least, there are 2 settings you might optionally consider changing :

  • if you are currently using the setting “shared hardware context”, you should probably consider turning it off, it adds rendering latency while it shouldn’t be necessary anymore with those changes (the cores that actually require this setting will force it).
  • if your GPU is less than 15 years old and your platform supports “glcore”, you should probably consider using “glcore” over “gl” as default OpenGL video driver, it generally produce better overall results.

Final Burn Neo Progress Report – September 2020

Final Burn Neo (FBN/FBNeo) is the follow-up of Final Burn Alpha (FBA/FBAlpha), an alternative to MAME for arcade emulation. It’s more focused on playability and less on accuracy/preservation. The team is composed of dink, iq_132, JacKc, kev and me. It supports most libretro features (netplay, runahead, retroachievements, …) and is part of the libretro steam launch lineup.

New supported games and other improvements

Konami

We added support for “WEC Le mans” and “Hot Chase”, 2 racing games from 1986 & 1988, you could see those games as Konami’s response to Sega’s “Out Run” and “Hang On”.
We also added support for the 6-player version of “X-Men”, which is playable from start to end without any glitch for the first time in an arcade emulator (our fixes were also ported to current MAME and MAME2003+).

We also improved emulation for the K054539 sound chip which is used in lots of konami games (including X-Men), this board had an echo effect that wasn’t emulated in any arcade emulator previously.

PGM

“Photo Y2K 2”, a game dumped nearly 20 years ago, finally got his protection passed thanks to the efforts of iq_132 and dink, i wouldn’t call it a must-play but it’s always nice to make breakthrough after so long. Various pgm hacks and bootlegs were also added along the way.

Sega

“Opa Opa”, a Sega System E game from 1987, is now playable, the game is some kind of mix between pacman and a shoot’em’up, with upgrades and playable in co-op.
Our Sega System 18 driver also had a nice overhaul after being on the todo list for a long time, games like “Michael Jackson’s Moonwalker” now plays without any gfx issues.
2 megadrive arcade bootlegs were also added : “Super Bubble Bobble” and “Top Shooter”.

Midway

For years there was a nasty issue with our Midway W/T Unit emulation (Mortal Kombat 1/2/3 and Rampage World Tour), more precisely only half of the frames were properly displayed, it has now been fixed thanks to the efforts of Marcos Medeiros (Romhack/zxmarcos) !

Taito

We added support for “Galactic Storm”, a third person shoot’em’up from 1992, this one was quite the unusual addition since it involves some polygon rendering, it’s quite rare for FBNeo to do 3D-ish things.

DataEast

“Gondomania”, a shoot’em’up from 1987, is now playable. “Super Shanghai Dragon’s Eye”, a puzzle/mahjong game from 1992, was also added.

Capcom

There was another batch of gfx fixes for CPS3 (Street Fighter 3, JoJo, Warzard), our emulation should now be on par with MAME’s apart from DMA status emulation, and there is a good reason for that : it would critically increase the hardware requirements for something that doesn’t seem to affect any phase of gameplay, that’s just not worth it on an emulator which is more focused on playability than accuracy/preservation. SF3-1 and SF3-2 from that driver also have a new dipswitch to enable wide screen mode (previously, only SF3-2 had that wide screen mode available, and only through its service menu), don’t ask about SF3-3.
CPS1’s (olders Street Fighter 2 and dozens of other games) MSM6295 sound chip also got nice improvements that make the bgm sound clearer, i’m mentioning it for CPS1 but it’s also used in quite a lot of other arcade systems. About that, i’ve seen some messed up comparisons on internet so i’ll say it : it’ll never reach the quality of cd/vinyl soundtracks of those CPS1 games, because it operates at a 7.5khz samplerate and the bgms were recorded for that samplerate.

SNK

Support for Neo-Geo Pocket and Pocket Color was added.

Nintendo

More NES mappers, more NES games, and reduced input lag ! If your favorite NES game isn’t emulated yet, feel free to ask here !

Miscellaneous

Pre 90s

Added support for missing games running on the same hardware as “Q-Bert”, it includes “Insector”, “Argus”, “Krull”, “Curve Ball”, “Tylz”, “Knightmare”, “Reactor”, “Screw Loose”, “Wiz Warz”, “Video Vince and the Game Factory”, and “The Three Stooges In Brides Is Brides”.
We finally completed our support for Nichibutsu games : “Tube Panic” and “Mag Max”, 2 shoot’em’up from 1984 and 1985, are now supported.

Post 90s

Support for “Hyper Duel”, a really nice Technosoft shoot’em’up from 1993, was added.

A “Cisco Heat” driver was added, it includes the eponym racing game from Jaleco, and other games like “Big Run”, “Grand Prix Star”, “Wild Pilot”, and “Scud Hammer”.
Support for the Hyperstone cpu family, high-spec cpus from the late 90s, was added, and along with it support for most arcade systems using them, it includes games like “Vamf x1/2”, “X2222”, “Crazy War”, and dozens of other games. I’ll be honest though, technically those games don’t live up to the specs of their cpus.

Better savestates support

Over the last months, savestate issues that could cause glitches, mostly with runahead (single instance) and netplay, were fixed, it includes neogeo, cps1, pgm, irem m92, sega system 1, and last but not least, pretty much any game using yamaha sound boards, and i can tell you those boards were quite popular in the 90s.

Better support for other archs/platforms (arm, PS3 and Wii U)

Final Burn Neo is written for x86 cpus, and while we try to keep the code compatible with other archs, we don’t always have the time nor means to properly test them. Lots of work was done on that front lately, it includes a few fixes for arm cpus (i.e smartphones, tablets and small computers like the raspberry pi), and tons of fixes for big-endian ppc cpus (i.e PS3 and Wii U). I’m not saying the ~15000 romsets we support are all ok, with an emulator which is basically a conglomerate of hundreds of smaller emulators it probably wouldn’t be even after working for years on it, but hundreds of games were fixed, including popular systems like pgm or neogeo CD. A special thanks to CrystalCT, author of FBNeoRLPlus (an alternative libretro frontend specialized in FBNeo for PS3), for his dedication on this.

And much more ! This article is far from being exhaustive.
If you want to help FBNeo, keep sending us bug reports when you see something wrong.
Our forum : https://neo-source.com/
Our github : https://github.com/finalburnneo/FBNeo
Our discord : https://discord.gg/8EGVd9v