Mesen - Emulator
Moderator: Moderators
Re: Mesen - Emulator
Sour, thanks. The Flintstones꞉ The Rescue of Dino & Hoppy (J).nes (PRG+CHR CRC32: 0x40C0AD47) game is not emulated correctly and there is no submapper handling for mapper 48. In Mesen 0.9.9 the game database had Mapper: 48 Sub: 255, now Mapper: 48 Sub: 0, but the code remained old _isFlintstones = _romInfo.SubMapperID == 255; (https://github.com/SourMesen/Mesen2/blo ... 0690.h#L24). In the emulator https://www.unlicensed.games/libg/stati ... dulatorNRS submapper 0 - Flintstones, submapper 1 - Jetsons (\src.7z\src-mappers\src\iNES\mapper048.cpp), but in Mesen the logic is reversed - the default behavior is like in Jetsons. In No-Intro and in your current game database like in NintendulatorNRS: https://datomatic.no-intro.org/index.ph ... =45&n=0776, https://datomatic.no-intro.org/index.ph ... =45&n=1101.
Re: Mesen - Emulator
Update on this: I managed to "fix" the problem by setting the SDL_VIDEODRIVER=x11 env variable on my end. This lets the SDL2 renderer work properly on my Fedora 41 VM. I changed the code to automatically set SDL_VIDEODRIVER=x11 and retry when SDL2 fails to initialize with the default settings. On my end, this lets SDL2 work without having to manually set any environment variable. With some luck the latest build might work on your end without enabling the software renderer?SteakedBits wrote: ↑Wed Mar 26, 2025 7:13 pm Just tried the native build, no dice.
It seems like the issue you linked to seems identical to what I am having, I'll be sure to keep an eye on it.
That's the hard part, I think - there are a lot of different video filters, and tweaking them to have the same output at 2x resolution would probably take a lot of effort. The bilinear interpolation option would still not work, even if I did, though, since that's a hardware feature I have no control over.creaothceann wrote: ↑Wed Apr 09, 2025 8:36 am Perhaps always outputting 512x448 and configuring the filters around that...
Thanks, looks like this is an old bug from the last time I updated the DB. I've fixed the code to use submapper 0/1 since that seems to be what NRS is using, too.
-
- Posts: 32
- Joined: Sat May 11, 2024 11:29 pm
Re: Mesen - Emulator
SD Keiji - Blader (Japan).nes
used to be mapper 082 but is now mapper 552 which is unsupported
used to be mapper 082 but is now mapper 552 which is unsupported
Re: Mesen - Emulator
Sour, I've been trying Mesen's LUA API, and I was rather confused by how it handles the alpha channel of colors. GetPixel returns normal ARGB, but the draw* functions expect the alpha value to be inverted, so if you just read a color from the screen to draw with it, it turns invisible inexplicably. Also the docs don't mention this behavior at all and suggest a consistent standard format.
Re: Mesen - Emulator
Unfortunately, in The Flintstones: The Rescue of Dino & Hoppy (J).nes there are incorrect tiles in the status bar if you enable "PPU $2006 scroll glitch emulation" and CPU/PPU alignment is set to default (Randomize is not enabled) and at some values (Randomize is enabled). It happens right at the beginning of the game, if you jump.
In Captain Saver (J).nes the status bar shakes, there submapper 0, if you select 1, then it is normal (as it was before the fix). Bubble Bobble 2 (J).nes also uses IRQ, but not at the beginning of the game, I have not checked.
Timing is different from NintendulatorNRS.
Re: Mesen - Emulator
This was probably an old bug with the getPixel API that was never noticed until now. This is fixed - getPixel will return the alpha value as 0 instead of 255, so that the color is compatible with all the other existing APIs. The draw APIs invert alpha values because this allows writing the colors more naturally as hex, like you would in CSS - e.g 0xFF0000 = #FF0000, otherwise you have to manually add an extra FF for the alpha value in every single color. It's been this way since ~2017, so can't really be changed at this point.Nezz wrote: ↑Fri Apr 11, 2025 11:27 pm Sour, I've been trying Mesen's LUA API, and I was rather confused by how it handles the alpha channel of colors. GetPixel returns normal ARGB, but the draw* functions expect the alpha value to be inverted, so if you just read a color from the screen to draw with it, it turns invisible inexplicably. Also the docs don't mention this behavior at all and suggest a consistent standard format.
FYI, if you're referring to the documentation on the website, this is for the old 0.9.9 version and very outdated, I wouldn't recommend using it. The most up-to-date documentation is available via the script window, in Help -> API Reference.
Thanks, I slightly tweaked the IRQ timing and both Flintstones & Captain Saver are fixed.
Re: Mesen - Emulator
I am referring to the in-program documentation. It gives all color formats (including getPixel's return value) as ARGB, doesn't mention any inversion of the alpha value and states that the default value for drawString's "backgroundColor" (i.e. "0") means transparent, even though -- being uninverted -- it's actually opaque black.
Re: Mesen - Emulator
Thanks! I fixed the incorrect comment about 0 being "transparent", since the default for drawString has always been a black background. Also added some notes/examples in a new section to explain the color format (and made every reference to "ARGB" in the documentation link to that section). Hopefully this makes things a little clearer for everybody.Nezz wrote: ↑Sun Apr 13, 2025 1:25 amI am referring to the in-program documentation. It gives all color formats (including getPixel's return value) as ARGB, doesn't mention any inversion of the alpha value and states that the default value for drawString's "backgroundColor" (i.e. "0") means transparent, even though -- being uninverted -- it's actually opaque black.
Re: Mesen - Emulator
On SNES, "Donkey Kong Country 2ꓽ Diddy's Kong Quest (USA) (Rev 1).sfc" the audio at the start when the "NINTENDO" logo appears is laggy and crackling. I don't have any filters on. Audio interpolation is set to default "Gauss".
Re: Mesen - Emulator
Does Mesen support the extended Super FX map with CPU ROM?
Re: Mesen - Emulator
I can't reproduce this, and someone else tested on their end, too, and they could not reproduce this either. It sounds identical in Mesen and ares on my end, with no crackling/lag in either emulator.
Do you have a link/info/test rom that you can share for this? The answer is probably no, since I'm not entirely sure what this is. My code appears to map ROM to 00-3F, and then mirror this to 40-5F, 80-BF, C0-DF. If this is incorrect, I can change it, though.
Re: Mesen - Emulator
The map I'm talking about can be seen in book2, page 2-3-2. Page 2-3-4 makes it clear that the GSU cannot see the "Super NES CPU ROM"; it's exclusively for the S-CPU, presumably wired in parallel with the GSU and its "Game Pak ROM".
Or, if you prefer another source (observe the SNES-side GSU2 map specifically): https://problemkaputt.de/fullsnes.htm#s ... nmemorymap
I'm using CPU ROM for my shmup port, and it sounds like Randy used it for the recent collector's edition of Doom (not that I expect you to emulate the "Super FX 3" any time soon...). [EDIT: boy, that aged poorly. Doom doesn't use CPU ROM, and the Super FX 3 is likely to show up in Mesen in the fairly near future.] Unfortunately I cannot provide a test ROM; progress on my port has been glacial and I have not yet mated the two halves of the engine. I'm asking this because I'm hoping to do so soon.
Last edited by 93143 on Sat Apr 19, 2025 1:33 am, edited 1 time in total.
Re: Mesen - Emulator
I reset all my settings to default and that fixed it. Could this have been caused by me updating Mesen for practically every new build and that caused a configuration to become messed up? Hopefully it’s not a glitch I overlooked.
Re: Mesen - Emulator
So does that mean the "GSU1" mappings that fullsnes lists are incorrect? Or are there different mappings depending on the specific cart/game? (in which case I guess this would need some heuristic to pick between either, since I don't think the rom header is useful here?)93143 wrote: ↑Mon Apr 14, 2025 3:18 am The map I'm talking about can be seen in book2, page 2-3-2. Page 2-3-4 makes it clear that the GSU cannot see the "Super NES CPU ROM"; it's exclusively for the S-CPU, presumably wired in parallel with the GSU and its "Game Pak ROM".
Or, if you prefer another source (observe the SNES-side GSU2 map specifically): https://problemkaputt.de/fullsnes.htm#s ... nmemorymap
I'm using CPU ROM for my shmup port, and it sounds like Randy used it for the recent collector's edition of Doom (not that I expect you to emulate the "Super FX 3" any time soon...). Unfortunately I cannot provide a test ROM; progress on my port has been glacial and I have not yet mated the two halves of the engine. I'm asking this because I'm hoping to do so soon.
Re: Doom, I know Randy has been using a slightly modified Mesen to develop it. Last I heard he was planning on giving me his code changes so I can integrate them once he's done, but still waiting on this at the moment.
Either way, tweaking the mappings is probably simple - it's mostly a matter of knowing how/when these mappings should be used over the "GSU1" mappings, and also having a way to test those mappings.
My best guess is that you had run-ahead enabled, which impacts performance considerably (or maybe some other options like overclocking, or some of the heavier video filters, etc.), and your PC couldn't run the game at 60fps as a result, which would result in the symptoms you described.
Re: Mesen - Emulator
I’m pretty sure I didn’t have run-ahead enabled. It was only during the Nintendo sequence every time at the start of that one title the audio would lag and crack, not video. And I seriously doubt a $4,500 gaming pc would lag on an SNES title with just audio at the start. LolSour wrote: ↑Tue Apr 15, 2025 2:48 amMy best guess is that you had run-ahead enabled, which impacts performance considerably (or maybe some other options like overclocking, or some of the heavier video filters, etc.), and your PC couldn't run the game at 60fps as a result, which would result in the symptoms you described.
But, if it happens again I’ll try to figure it out and report it as best as I can describe. Maybe I can share configuration file if it happens again.