sssv VS mupen64plus-libretro-nx

https://github.com/mkst/sssv Space Station Silicon Valley

I do something similar for my sssv decomp - you might want to look at on_pull_request_target so forks can run the action (without getting the secret) - otherwise anyone else submitting a PR will have the action fail). Have a look at the job here: https://github.com/mkst/sssv/blob/master/.github/workflows/build_pr.yaml

You can find previous core builds by downloading the RetroArch_cores.7z file that is next to each stable version, it include all cores as they were at the time of compilation of the stable version of RetroArch. For example, I'm holding the 12/6/2021 build of Mupen64Plus-Next due to this particular bug. The problem is, RetroArch has gone a few months without stable releases, so you'll have to see if these builds are good for you, recent enough to support the games you want and not new enough to have the recent bug.

I think the best course of action is to open an issue here: https://github.com/libretro/mupen64plus-libretro-nx. You can reference this thread.

The repo is here if you want to try building it yourself https://github.com/libretro/mupen64plus-libretro-nx

Yes https://github.com/libretro/mupen64plus-libretro-nx/issues/100

Seems cool if you'll only use GLideN64 and cxd4, which are great in their own right, but it doesn't seem to include parallel-rdp and parallel-rsp, which are responsible for the unique accuracy breakthroughs in N64 emulation I mentioned. As far as I know no standalone fork of Mupen have integrated these yet. It's quite the piece of work that was done in this core https://github.com/libretro/mupen64plus-libretro-nx m4xw works mainly on the Switch, but this core has become the main Mupen core in every platform since.