1.62.1 no music with msu-1 hacks and freezes on videos

[p3st-textures]

i just wanted to notice a thing ^^

like the title said i get no music or sounds anymore form the msu-1 stuff , tryied a few games... nothing also my alttp uses the intro video patch , at the video snes9x freezes now super roadblaster doesn´t even start .

with the last version everything works fine

[OV2]

What style of msu are you trying to open, and what platform are you using?

I tried an uncompressed msu (sfc, bps and msu/pcm files in the same folder, chrono trigger) as well as a .msu1 pack (super road blaster) - both worked fine.

[p3st-textures]

i have only uncompressed msu games ...and thats strange for me the games work but not the music , and as i said video freezes

i use the core version over retroarch on win 10 64bit ...with the gl video driver btw

https://streamable.com/nbg5td here a quick demonstration it works fine with 1.61 for me ^^

[OV2]

This should be fixed, can you try the latest auto-generated build?

[p3st-textures]

autogenerated build where can i get that ?

NEVERMIND found it ^^ and works again THX

[ds22x]

https://github.com/snes9xgit/snes9x/commit/33d84d31b8b86e10a3d0638d1282ce2f0063d414#diff-08fd608692cc3277cc9ae722ea56caf18db9987aa039e62485c91d8258185008R1129 seems to be causing issues when trying to connect through netplay on RetroArch.

[OV2]

Can you describe this in more detail? It worked fine when I tried it with two instances on my system, connecting to one from the other.

[ds22x]

The problem is that, when passing the game path, it expects it to be exactly at that path, hence why it works with two instances on the same system, but not when trying to connect two separate systems (I.E. two Windows setups where the rom is located at different paths etc.).

[ds22x]

Found the solution. https://github.com/snes9xgit/snes9x/pull/848

[OV2]

The problem is not the loading of the rom, since LoadROMMem always loads from memory. The path is simply passed to the core so that S9xGetFilename can later be used to retrieve the rom path for possible other files (msu1 etc.).

Retroarch throws "Netplay state load with an unexpected save state size.". The problem is that the ROMFilename is part of the save state, which is why different names get different state sizes.

@bearoso: with the new S9xGetFilename in fscompat the port can no longer override this function, which is problematic if we want the ROMFilename to be a fixed string and still make msu1 etc. work. Should we add a define for this? Any better ideas?

[ds22x]

So I assume using g_basename instead of game->path is not a good solution?

[OV2]

This would work for cases where the rom filename is the same for all netplay parties. But if one party has the rom named super_mario.sfc, and the second party has named it mario.sfc you'd run into the same issue again.

[ds22x]

Tried a 1.61 core, and it also refuses to connect when the roms don't share the same name. Also tried the same setup with a completely different and unrelated core setup (PicoDrive in this case) to check if only Snes9x refuses the connection with differently named roms, but the same thing occurred.

[bearoso]

@bearoso: with the new S9xGetFilename in fscompat the port can no longer override this function, which is problematic if we want the ROMFilename to be a fixed string and still make msu1 etc. work. Should we add a define for this? Any better ideas?

An #ifdef around S9xGetFilename is fine if they need to have a special copy.

[OV2]

Tried a 1.61 core, and it also refuses to connect when the roms don't share the same name. Also tried the same setup with a completely different and unrelated core setup (PicoDrive in this case) to check if only Snes9x refuses the connection with differently named roms, but the same thing occurred.

I just tried this with 1.61 and it worked without problems. Maybe you ran into the issue that retroarch seems to autoupdate cores when starting netplay?

I'll try to do a fix that allows it again.

[ds22x]

I did run into that initially, but I made sure to lock the cores from being auto-updated after that, so that's not the problem.

[bearoso]

Can we just pad out the romfilename field in the save state to a fixed size, then? Or even just zero it out? I don't think we're actually doing anything with that info, because replacing the actual filename after loading a game makes no sense.

[OV2]

Sure, we could simply pad and/or truncate. Truncating would make sense anyway, since the buffer when reading is fixed to PATH_MAX.

I guess it was meant to have a way to find the rom for a state? You're right, it's not used anywhere, so we could also just set it to an empty string.

[bearoso]

I just set it to the word "Removed" It'll always be the same size now, so we shouldn't have that problem.

[OV2]

Finally got around to try it again, works fine now for different rom paths and rom names.