Mesen-S (SNES) core

Libretro Cores
#1

As some of you might know already, I’ve been working on a SNES emulator for the past few months. I finally got to a fairly decent point in terms of compatibility/accuracy, so I spent a couple of hours porting over the libretro code from Mesen to this one.

Edit: Removed outdated information related to things that weren’t supported yet, and known bugs. Mesen-S should now be able to run the vast majority of the SNES library, with the exception of a handful of games that still have issues.

If you find issues in games (freezes, broken graphics, etc.), please let me know (either by posting here, or opening an issue on github)!

The repository is here:

The instructions for compiling the libretro core on Windows/Linux are in the COMPILING.md file. Windows, Linux and Android builds are also available on the buildbot.

12 Likes
#2

That’s amazing news ! Mesen is my favorite nes emulator ! Do you also plan on adding a HD pack feature in the future ?

Afaik, if you expose the ram for RetroAchievements, it should also allow cheats to work (it’s working in my FBNeo core).

2 Likes
#3

Mesen is my favorite NES emulator too.

#4

Very exciting! and wow, cycle accurate! I know you mentioned that A.S.P.'s shadow works, too, so I take it you have a dot-granular PPU, as well?

#5

Nice to see that there’s some interest despite being at such an early stage of development!

It’s a possibility, but I don’t have any solid plans for it at the moment. I’m not sure how feasible it would be, considering how much more complex the SNES’s PPU is. Plus, factor in the fact that creating a HD pack for a SNES game would probably a lot more consuming than for NES games (and NES games can get extremely time consuming as it is!) - I’m not sure if there would be enough interest for it.

I did expose the save & work ram, but not the rom in any way, so I’m guessing that while achievements might work, any rom-based code would probably fail at the moment. Also, not sure if RetroArch supports game genie code and the like natively?

More or less - currently it’s more of a scanline renderer that can be interrupted at any point during the scanline to reflect any changes done to the PPU. It’s good enough for a lot of things (including that shadow), but it’s lacking the real “pipeline” that the PPU uses to draw stuff on the screen (e.g read the tile data a short amount of time before actually drawing it, etc.). This causes some issues in some games because the updates to the PPU are taken into account too fast by the rendering. Re-working the PPU’s code to fix this is one of the next things on my list.

#6

Very interesting! I was around when byuu started working on his dot-based PPU (what would become the backbone of the “accuracy” profile) and I recall that he was drawn then to the everything-just-works simplicity of going that granular, but the impact on performance for the benefit of a single game was convincing enough even to him to keep the scanline-based PPU around for many years.

I’m curious to see how your middle-of-the-road approach turns out!

1 Like
#7

It doesn’t like “Sync to Exact Content Framerate” enabled at startup. It seems like it runs at half speed if that’s enabled. Disabling it doesn’t fix it until you restart RA.

#8

Also, the core options should probably have -S appended to them so they don’t get mixed in with Mesen (NES) options in the core options file.

#9

Thanks! Both of these should be fixed now.

1 Like
#10

Thanks! I have a few other thoughts:

Someone mentioned this on discord; it’d be nice to have some options for how high res mode/framebuffer size is decided. Something like:

Auto: Uses 240 except when high res elements are onscreen. This is how snes9x and BSNES Balanced do it. Looks nicer for shaders.

Always: Always render at 480. Current behavior. Maybe more accurate in certain cases.

Off: Always render at 240. snes9x has an option like this to disable high res mode. Looks best for shaders, but high res text ends up mangled. I use this mode in snes9x for Kirby’s Dreamland 3 since I use a romhack that blends the interlaced transparency effect down to 240.

Mesen-S doesn’t want to load my Trials of Mana save from snes9x for some reason. Saves from Ys V and Sailor Moon: Another Story work fine. Here’s the save: https://www.dropbox.com/s/ko1f7xt89kotaxc/Trials%20of%20Mana%20snes9x%20Save.zip?dl=0

#11

I’ve actually been wondering how other emulators handle this, but hadn’t had the time to check yet. The reason it’s currently rendering at 480p is purely for simplicity - it was simpler to get it working this way (the standalone build works this way too, it’s not a libretro thing). I’ve been meaning to fix this (esp. since it makes stuff like the xBRZ filters pretty much useless in the standalone build). Will try to get around to fixing this relatively soon.

I forgot to disable the built-in battery system in Mesen-S for the libretro build, too, which probably means both RetroArch and the core itself are trying to load and save the srm file. Might be unrelated though, since other games work. Thanks for the save file, I’ll take a look soon.

1 Like
#12

Great news a new SNES libretro core will be released! As a user of CRT-Switchres I wonder, will this core (eventually) output all native resolutions like the real snes does? Many snes games switch resolution in-game, to and from both progressive and interlaced so it would be nice if it is supported.

#13

This should be fixed as of the latest commit - was a bug with the memory mappings for that type of cartridge.

Do you mean like what was being discussed above? e.g 240p vs 480i resolution? In that case, yes, I do want to fix it so the core does not always output a 512x480 picture (esp. since it’d be just a little bit faster for all games that don’t use the hi resolution modes)

2 Likes
#14

Nice work, thanks :smiley:

#15

Yes, I guess, but in that discussion it seemed as if resolutions have to be switched by a setting before playing a game.

What I mean is, will Mesen-S output resolutions on the fly as a game demands it (like Super Family Tennis) like on the real snes, so between 256×224 and 512×448 (NTSC), or between 256×240 and 512×480 (PAL)?

#16

This should be the default behavior now as of the latest commit - switches between 512x478 and 256x239 as needed based on the content of the frame. There’s no option to force 256x239 resolution just yet, though.

Yep, it does as of the latest commit - though it won’t switch between 224p and 239p, since games tend to switch between those from one screen to another, which would probably look rather odd (King Arthur’s World does this). If you want the 224p resolution, you can set overscan to cut off 8px on the top/bottom.

2 Likes
#17

Cool! I see the core on the Win64 buildbot now. Looks like this change isn’t on that yet; I’ll check it out later.

I did a quick frame advance lag test comparing snes9x and Mesen-S with Mario World. I get two lag frames (three k presses) when jumping in snes9x and three (four k presses) in Mesen-S. I think Mesen also had an extra lag frame compared to the other NES cores when it was initially libretroized. Maybe the same fix for that would apply here?

#18

Seems it’s not on the Linux buildbot page :frowning:

#19

Great, will try it out soon and post some feedback.

#20

I noticed when in high res mode, it seems to be higher res than snes9x? Here are comparison shots between the two: http://www.framecompare.com/image-compare/screenshotcomparison/2F1MNNNU

snes9x ends up looking better with the shader in high res mode. Also, it seems like Mesen-S is cutting off an extra line at the top with vertical overscan set to 8px compared to snes9x with crop overscan on (which should also just do 8px). If I enable integer scale and set the custom aspect ratio height and width options to 1x, snes9x shows 256x224 and Mesen-S 256x223.