Deprecate the bsnes/higan snes forks?

With current versions of BSNES being focused on performance, and there being way too many different BSNES versions to pick from (I counted 12 of them on the Core Updater!), maybe it’s time to deprecate and hide the older bsnes/higan forks.

2 Likes

That is a goal everyone has in mind but current bsnes needs most of its features to work before that: SGB/BSX, save states working with rewind and run ahead, MSU1, etc.

We could lose a lot of them.

  • Beetle-snes is just a really old fork for bsnes (circa v060 or so)
  • bsnes c++98 is only notable for being able to compile on platforms that don’t have modern compilers, so there’s no point in having it/them on PC
  • bsnes2014 is redundant with mercury so one of those sets can go
  • 2014/mercury-accuracy should be superseded by higan v106 (or new bsnes with accuracy-focused settings)
  • 2014/mercury-performance is not really any more accurate than up-to-date snes9x but it’s a lot slower, so it can probably go, too.

That leaves us with modern bsnes, higan v106 (which could arguably go now that modern bsnes is on the come-up) and bsnes2014/-mercury-balanced for cheats and achievements, etc. (i.e., full libretro featureset). Platforms that both need and can run bsnes-c++98 (which I think is technically no platform) will only be able to build it anyway, so there’s no problem there.

While I don’t think those obsolete cores need to actually go anywhere (like deleted repos or whatever), they don’t need to be built and distributed, IMO.

Meaning old platforms that won’t run it at fullspeed anyway ?

yeah, the only one I can think of that would actually benefit from that core is haikuOS, and maybe not even that if they finally moved up to a newer GCC. It was v4.2 last time I used it, but that was several years ago.

Could we have core subfolders to segregate the 95% of current /active cores vs non-maintained ones? Could also be used to stage development ones so we can get a feel for the maturity of each.

One thing I’ve noticed is that MSVC will perform profile-guided optimizations much faster on simple C code than complicated C++ code. By “Much Faster”, I mean that MSVC will take hours on the complicated C++ code and seconds on the simple C code.

So that could justify a more simple code version, if you are producing Profile-Guided optimized versions.

In addition, the bsnes_libretro core is missing the core information file, so it has no name, and can not handle any file extensions.

Edit: Needed to update Info files… weird how triggering the core downloader doesn’t do this for you.

It does have an info file. It’s just that some packages of RetroArch (like the PPA) are unable to download new core info files due to a broken default configuration.