Slight audio crackle/stutter/glitching during fades/transitions in Pokémon Mystery Dungeon: Blue Rescue Team about melonds HOT 5 CLOSED

The game might be writing to SRAM, currently melonDS dumps a copy of the entire SRAM to the drive for every write. Try to see if it also happens in the official melonDS release and if it does create an issue upstream if it already does not exist.

from melonds.

Alright, it seems to be an upstream issue, created one there. Should this stay open as well?

from melonds.

🤷‍♂️

from melonds.

I was thinking of mentioning this few minutes ago, right before looking at the issue section here and noticing this thread. This synchronous-only saving method that melonDS has right now is unfortunately one of the most annoying issues, at least when using the current libretro core.

I remember it was brought up and discussed already when @m4tsa updated this core to latest master, but just for the sake of understanding this I am wondering if making the libretro core output a .srm file instead of a .sav file, essentially hooking the libretro save API fully (I presume?), would address this matter and make the process asynchronous.

Maybe it could be available as a core option similarly to what beetle-psx does, where the user can choose based on their own discretion if they prefer to output saves with the .srm format (libretro) or the .mcr format (PS1 memory card file). But again, I do not know how feasible this is without disrupting core maintainability and I’m wondering if this would even address the “fully synchronous saves every time” thing in the first place.

from melonds.

I was thinking of mentioning this few minutes ago, right before looking at the issue section here and noticing this thread. This synchronous-only saving method that melonDS has right now is unfortunately one of the most annoying issues, at least when using the current libretro core.

I remember it was brought up and discussed already when @m4tsa updated this core to latest master, but just for the sake of understanding this I am wondering if making the libretro core output a .srm file instead of a .sav file, essentially hooking the libretro save API fully (I presume?), would address this matter and make the process asynchronous.

Maybe it could be available as a core option similarly to what beetle-psx does, where the user can choose based on their own discretion if they prefer to output saves with the .srm format (libretro) or the .mcr format (PS1 memory card file). But again, I do not know how feasible this is without disrupting core maintainability and I’m wondering if this would even address the “fully synchronous saves every time” thing in the first place.

No it will not since the melonDS code has no way currently to detect when you are done writing to the SRAM so it would still write the entire file for every byte written

from melonds.