Mesen-S (SNES) core

[Sour]

Seems it’s not on the Linux buildbot page

Yea, I keep meaning to get around to mentioning that so we can get it fixed, but keep forgetting about it!

I think Mesen also had an extra lag frame compared to the other NES cores when it was initially libretroized.

Yup, same bug, same fix (applies to the standalone build, too) - thanks!

Also, it seems like Mesen-S is cutting off an extra line at the top with vertical overscan set to 8px

That’s because the picture is 239px, so cutting off 16 ends up making it 223. I changed it to only cut off 7px at the top, so the picture should be 224px as expected now.

Can you re-test the shader and see if this makes any difference? If not, I’ll have to investigate what snes9x does differently - I’m just outputting a typical 512x448/478 picture when in high resolution modes.

Also, I just committed a fairly large change that rewrites a good portion of the rendering code for the PPU to make it a lot more accurate (fixes a couple of minor issues), the performance should be essentially the same as before, though. But it did touch a lot of code, so if you notice any weird visual glitches in games that weren’t there before, please let me know!

[Awakened]

Can you re-test the shader and see if this makes any difference? If not, I’ll have to investigate what snes9x does differently - I’m just outputting a typical 512x448/478 picture when in high resolution modes.

It looks the same as before, just with that scanline shown now: http://www.framecompare.com/image-compare/screenshotcomparison/2FEMNNNU

Also, I didn’t realize I could simply compile with mingw like other cores. Don’t have to wait for the buildbot now to test changes

[Awakened]

After the Masaya logo in Assault Suits Valken, the top active scanline displays some weirdness when the screen starts scrolling down:

Seems like a bug; not there in snes9x at least.

Edit: Checked with bsnes standalone and it’s not there either.

[Sour]

After the Masaya logo in Assault Suits Valken,

Thanks - looks like it might have been a recent regression. I was working on some more rewriting/refactoring for the PPU’s code (this time to improve the accuracy for the sprites) and it looks like those changes ended up fixing that bug, too - should be fixed if you grab the latest version of the code.

Also (partially) fixed the mosaic effect yesterday - I’m hoping that it works properly in standard resolution modes now (but it’s still completely broken in high resolution modes)

It looks the same as before

I might know what it is, there’s a part of the libretro setup where I always set the “base” resolution to 256x239, maybe that has an impact on the way the shaders work, will take a look when I have a chance.

Seems it’s not on the Linux buildbot page

The x64 linux builds should be up on the buildbot now (along with android builds, though that hasn’t been tested)

[Awakened]

Thanks - looks like it might have been a recent regression. I was working on some more rewriting/refactoring for the PPU’s code (this time to improve the accuracy for the sprites) and it looks like those changes ended up fixing that bug, too - should be fixed if you grab the latest version of the code.

Also (partially) fixed the mosaic effect yesterday - I’m hoping that it works properly in standard resolution modes now (but it’s still completely broken in high resolution modes)

Valken is good now. The mosaic looks better, but still different from snes9x in Mario World when you enter a level from the map screen:

[Sour]

but still different from snes9x in Mario World when you enter a level from the map screen:

Thanks! This should be fixed now (also fixed another mosaic issue in ghosts and ghouls).

[Awakened]

Tested some more games today.

DKC 1 and 2 activate high res mode on the Nintendo Presents screen in Mesen-S, while they don’t in snes9x.

This might be an interesting sound edge case. The crappy sounding intro music Transcorp added to their translation of Emerald Dragon sounds like it’s missing some chords or something in Mesen-S compared to snes9x. Once you get past their intro it sounds fine.

The mosaic effect in FFVI/III when a battle is initiated looks wrong; just like it did in SMW before your fix.

In Link to the Past, snes9x and bsnes usually show some random colored pixels somewhere in the blackness on the Nintendo Presents screen. They don’t show up in Mesen-S. I think I’ve seen recordings of real hardware showing them before.

Super Puyo Puyo 2 with this translation patch is missing the a’s from dialogue before matches in the story mode. They’re there in snes9x and bsnes standalone.

[Tatsuya79]

Th t’s n origin l bug.

[Sour]

In Link to the Past, snes9x and bsnes usually show some random colored pixels somewhere in the blackness on the Nintendo Presents screen.

Turn on the “random ram” option in the core settings (added it a couple of days ago) and it should make them appear. Haven’t had the chance of looking at the other ones yet, but will try to get around to them tonight, thanks!

Th t’s n origin l bug.

Took me a lot longer than I’m willing to admit to figure this one out…

[Sour]

DKC 1 and 2 activate high res mode on the Nintendo Presents

This seems to be normal - the games turn on high res mode midway around the screen until the end of it. Maybe snes9x doesn’t switch to high res output unless the entire screen is high res?

The mosaic effect in FFVI/III when a battle is initiated looks wrong

This should be fixed, thanks!

Super Puyo Puyo 2 with this translation patch is missing the a’s

Looks like this is a “bad” romhack - the glitch only happens when you set the default ram state to 0, so it looks like the romhack isn’t initializing memory properly.

sounds like it’s missing some chords or something in Mesen-S compared to snes9x

I can’t really see any difference… The volume on Mesen-S is definitely lower than snes9x’s, maybe that’s what’s making you think there’s something missing? Part of the music is pretty hard to hear in Mesen-S without increasing your audio volume. FYI, both Snes9x and Mesen-S use the exact same DSP code (I think higan does too, actually?) - it’s the one written by blargg some years ago. It’s definitely possible that there’s a bug somewhere on the SPC side of things, though, since that’s my own code.

Thanks for taking the time to test all these games, by the way, really helpful!

Also, did some more sprite-related changes to improve accuracy again. So if you notice anything broken with sprites, let me know.

[Awakened]

This seems to be normal - the games turn on high res mode midway around the screen until the end of it. Maybe snes9x doesn’t switch to high res output unless the entire screen is high res?

I guess it’s possible. I’m not sure if the entire screen goes high res in Trials of Mana when high res text is displayed.

Looks like this is a “bad” romhack - the glitch only happens when you set the default ram state to 0, so it looks like the romhack isn’t initializing memory properly.

Interesting. It’s a really old hack, so I’m not too surprised it has issues. Though is using random RAM technically more accurate than all 0’s?

I can’t really see any difference… The volume on Mesen-S is definitely lower than snes9x’s, maybe that’s what’s making you think there’s something missing? Part of the music is pretty hard to hear in Mesen-S without increasing your audio volume. FYI, both Snes9x and Mesen-S use the exact same DSP code (I think higan does too, actually?) - it’s the one written by blargg some years ago. It’s definitely possible that there’s a bug somewhere on the SPC side of things, though, since that’s my own code.

I made a comparison, but while I was doing it, one time it played the music the same as snes9x. All I did was turn up my windows volume and reset the game. Tried restarting RetroArch and doing that again and couldn’t get it to play right again. General volume seems the same in both cores for me. It’s just this intro track that seems to be missing notes. Tried changing RAM state to random just to see if that would fix it, but it didn’t. Here’s the comparison of the second part of the track, snes9x first, Mesen-S second: https://www.dropbox.com/s/vzmeadrhfvoimdc/edcompare.wav?dl=0

All I did was amplify the entire recording, since Audacity always records at a low volume. Seems like the notes aren’t there at all instead of just being quiet.

Thanks for taking the time to test all these games, by the way, really helpful!

Also, did some more sprite-related changes to improve accuracy again. So if you notice anything broken with sprites, let me know.

No prob, thanks for looking at and fixing stuff! I’ll let you know if I notice anything.

[Sour]

Though is using random RAM technically more accurate than all 0’s?

Yes, random ram makes more sense than all 0s. While it’s possible that the power on state of RAM has a certain pattern to it, whatever pattern will tend to vary from one unit to the other, and the odds of it being all 0s are pretty much 0. I should probably make random ram the default, as far as I know that’s what higan does, too (except for save ram, I think).

Tried restarting RetroArch and doing that again and couldn’t get it to play right again.

Sadly it looks like I’m the opposite - I can’t get it to not play the notes. I even tried compiling on the libretro build on mingw just in case (instead of MSVC), and still plays them every time. It’s possible there’s some uninitialized variable somewhere, I’ll try to see if I can track it down using valgrind when I have a chance.

[Awakened]

I tried compiling a new build as well as trying a build from the buildbot with my sound cranked and resetting a few times and couldn’t get the notes to play again.

[Sour]

Tried finding/fixing uninitialized variables, but it unfortunately hasn’t changed anything on my end. If you still have the same issue with the latest code, could you try the standalone build (builds are on appveyor, linked in the readme on github) and see if you get the same behavior there? Also, just to be sure I’m listening to the right portion - the missing notes are just after the dragon flies by at the beginning, right?

Spent most of the day yesterday refactoring a bunch of PPU code to improve performance - it should be running roughly 30% faster than before (although I haven’t tested the libretro core specifically). I might have broken some things in the process, though - still need to do a bit more regression testing, but it seems to be working properly so far.

I also (probably) fixed the mosaic effect in high resolution modes - seems to be identical to higan’s behavior on the test rom I tried it on. Just need to implement it for mode 7 and then I should (finally) be done with it.

[Awakened]

Tried finding/fixing uninitialized variables, but it unfortunately hasn’t changed anything on my end. If you still have the same issue with the latest code, could you try the standalone build (builds are on appveyor, linked in the readme on github) and see if you get the same behavior there? Also, just to be sure I’m listening to the right portion - the missing notes are just after the dragon flies by at the beginning, right?

Yeah, when the two characters start walking up. I tested stand alone DevWin-0.1.0.77 and the notes aren’t there either for me.

Spent most of the day yesterday refactoring a bunch of PPU code to improve performance - it should be running roughly 30% faster than before (although I haven’t tested the libretro core specifically). I might have broken some things in the process, though - still need to do a bit more regression testing, but it seems to be working properly so far.

Was getting about 184 unlocked fps on a libretro buildbot build from yesterday sitting on SMW’s map screen with an i5 2500k at 4.4ghz. Today’s build is at 223fps. Not bad. A mingw build is at about 216fps. snes9x is around 960fps (phew!).

[hunterk]

it should be running roughly 30% faster than before

whoa, nice! gj, dude!

[Sour]

I tested stand alone DevWin-0.1.0.77 and the notes aren’t there either for me.

That’s really odd… Just to be sure that we’re using the same file, my patched rom with the english translation has the following SHA1 hash: 179f0e82e84bb78333cc330b53b9bbb21fa441fd

I just finished adding DSP-1/2/3/4 support, so Mario Kart/Pilot Wings/etc should now be playable. This uses LLE, so it requires a 8kb bios file named “dsp#.rom” (# varies based on the DSP version that the game needs). This should be in the “System/Bios” subfolder (but I haven’t had the time to test the libretro core)

[Awakened]

That’s really odd… Just to be sure that we’re using the same file, my patched rom with the english translation has the following SHA1 hash: 179f0e82e84bb78333cc330b53b9bbb21fa441fd

Well crap. Looking at the SHA1 made me realize I was using version 1.1 of the patch. Looks like they fixed stuff in the intro for flashcarts in 1.2. That version sounds perfect in Mesen-S. Sorry about the run around with that, but mystery solved at least.

[Awakened]

BTW, I just compared the Nintendo Presents screen in DKC1 in snes9x with hires mode on and off and it does use hires on that screen if it’s enabled. I just didn’t notice it since hires in snes9x doesn’t sharpen the CRT shader I use as much as Mesen-S.

[Sour]

Sorry about the run around with that, but mystery solved at least.

No worries! Good to know it’s working as expected and isn’t some weird unreproducible bug.

RE: High resolution, good to know it’s acting the same. Still need to look into the reason why it’s behaving differently with Mesen-S vs shaders.

Also: just finished adding support for the ST010/ST011 chips (which are essentially 95% the same as the DSP one).