Could not find much info on that. Can someone explain the difference between libretro bsnes, bsnes 2014, and mercury?
Thank you.
I’m assuming that bsnes 2014 would just be based on older code of bsnes, maybe to help people run it on lower-end machines.
This is what I found for bsnes mercury on https://emulation.gametechwiki.com/index.php/Bsnes
This fork aims to restore functionality like HLE DSP chip emulation and SGB emulation using Gambatte that was removed in later versions of bsnes, as well as to have some optimizations that don’t affect emulation accuracy. It also has an option to overclock SuperFX. Default options make it exactly the same as regular bsnes, with LLE DSP chip emulation enabled. This fork is only available as a libretro core, though it is possible to build it with Ethos (byuu’s frontend) instead.
Perhaps, but the “bsnes” core (no suffix) doesn’t state if it’s older or newer and why 
In my experience, the one with no suffix has been the newer one, similar to the naming conventions for Snes9x, and MAME cores
That’s what I would assume, but it begs the question of why 2014 exists. I doubt it’s for compatibility since bsnes was pretty much a completed project and that it already provides a performance-oriented core.
This information is all available in the core downloader. If you hover over a core and press retropad-select, it’ll pop up a description dialog that explains the differences between various cores for a given system/platform.
That said, bsnes-mercury and 2014 are a bit redundant, as they share the same codebase, aside from the aforementioned special chip HLE and SuperFX stuff. 2014 was originally kept back as a “vanilla” bsnes experience because a lot of bsnes users are/were weird about any changes, whether they understand the implications or not.
Ultimately, the additions to the mercury fork that were so controversial and maligned at the time were implemented into upstream bsnes once it was broken off from the totally accuracy-focused higan, as well.
Both bsnes2014 and -mercury differ from the up-to-date bsnes* cores mainly in their libretro integration. The later bsnes/higan codebases did not expose memory in such a way that allows frontend cheats and achievements without really digging into and breaking up the upstream core code, so if you want achievements plus bsnes, you need to use one of the older cores. I believe the later cores may also bypass the libretro save interface, meaning things like SRAM auto-write don’t work, either, but I’m not 100% on that.
Similar to the mercury situation, bsnes without anything after it is just the vanilla based-on-Near’s-upstream bsnes, while bsnes-hd-beta is based on derkoun’s modified upstream (the name is derkoun’s choice; they wanted to differentiate their potentially wonky/funky version from Near’s official version without the implication that the “HD” version was actually “better”, since its main draw is the high-def mode7–which is literally HD–while many popular games adopt the “HD” tag as a buzzword to mean “new/better”). High-def mode7 is incorporated into mainline bsnes now, but the bsnes-hd-beta core includes a few other things, like high bitrate gradients (no banding, where applicable) and high-def windowing effects, that are still experimental.
4 Likes
Damn, I never knew about that…
Thank you for the thorough explanation though!
1 Like
Should copy and paste this onto the BSNES libretro page. 