I'm still not sure why it would be crashing some of the time, but I think I understand what's going on with the "An error has occurred" screen, at least. With the old code, due to a side effect of how it was implemented, if you made a file smaller, the game would read zeroes when trying to access the now deleted part of the file. The newest version of Dolphin instead tells the game that the read failed if it tries to read from the deleted part of the file. (The times that you're not getting that screen, I'm assuming that the game didn't try to read from the deleted part of the file.) It wouldn't be impossible to add this behavior back to Dolphin, but it feels like kind of a hack to me... Do you get the same result as in old versions of Dolphin if you pad the file with zeroes so that it has the same size as it originally had? If so, would that be a workable solution for you, or is it too inconvenient?
(02-10-2020, 05:46 AM)JosJuice Wrote: [ -> ]Do you get the same result as in old versions of Dolphin if you pad the file with zeroes so that it has the same size as it originally had? If so, would that be a workable solution for you, or is it too inconvenient?
Right. That's the workaround most people have been satisfied with. I don't mind really at all because I patch the game via a different method (or in the rare cases I do use an extracted ROM, I need to reset the game anyway), but a small percentage of modders do use an older version of Dolphin or something else entirely to modify the game especially because of this issue.
JosJuice, I've tested the behaviour with the Dolphin version you suggested:
For me, the game freezes consistently when I try to decrease the level filesize. There's no generic Wii message (maybe they can be disabled in Settings). Dolphin gets stuck while displaying 100%/60fps/60vps. There's no other error message.
Our developers have added an option to Reggie Level Editor, which allows to pad a level with null bytes, just as you suggested.
This makes it possible to edit levels "on-the-fly". But that's only true for the level .arc itself and not any other assets (tilesets, sprites...). Games other than NSMBW also don't work, obviously.
Could there be a general solution, something like an "on-the-fly testing mode" for Dolphin? In that mode, all filesize checks are disabled. This could be achieved by setting the filesizes in fst.bin to arbitrarily high values. Or maybe force the emulator to read a file from any position, even if it is in a (presumably) deleted area or beyond the end of the file.
(02-10-2020, 09:36 AM)Zementblock Wrote: [ -> ]Could there be a general solution, something like an "on-the-fly testing mode" for Dolphin? In that mode, all filesize checks are disabled. This could be achieved by setting the filesizes in fst.bin to arbitrarily high values. Or maybe force the emulator to read a file from any position, even if it is in a (presumably) deleted area or beyond the end of the file.
If you want to support both making files smaller and making files bigger, you would need to set the file sizes in the FST to arbitrarily large values like you described. However, we can't make the disc bigger than 16 GiB due to how the game communicates with the disc drive, so the amount of extra space that we can reserve per file would be limited to (16 GiB - data already used up) / number of files. In addition, putting that much extra space between files could make the emulated loading times quite a bit worse (unless you enable the SUDTR setting, which as usual can break certain games). It could be implemented, I'm just not sure if it's worth it. Do you think it would be a useful feature despite these restrictions?
Personally, i would be fine with smaller filesizes alone, don't know about others though.
(02-10-2020, 06:33 PM)JosJuice Wrote: [ -> ]If you want to support both making files smaller and making files bigger, you would need to set the file sizes in the FST to arbitrarily large values like you described. However, we can't make the disc bigger than 16 GiB due to how the game communicates with the disc drive, so the amount of extra space that we can reserve per file would be limited to (16 GiB - data already used up) / number of files. In addition, putting that much extra space between files could make the emulated loading times quite a bit worse (unless you enable the SUDTR setting, which as usual can break certain games). It could be implemented, I'm just not sure if it's worth it. Do you think it would be a useful feature despite these restrictions?
Just curious - is there a list of games that break with speed up disk transfer? I always enable it because I personally care more about faster loading times than accuraet loading times (I understand many will disagree) and I've never had a problem so far, but I'm curious as to what games break simply because of being able to load faster. I'm sure they exist, but I've never encountered one.
There's no list as far as I'm aware, but to provide an example, the music in Super Smash Bros. Melee can stop working if you use it.
Tons of games can crash too. I know Rogue Squadron 2/3 had issues relating to it when they were running way back when, but I think other fixes to how Dolphin synced things.
Thanks for looking into it and your support!
Tbh, I was already fine with the padding solution in Reggie, as that covers most of the situations where the emulator had to be restarted due to level filesize changes.
On the other hand, if any other file is edited, then it's usually random, whether the size increases or decreases (for me it increases in more cases than it decreases), so if it's not too much work then I'd very much welcome the solution you suggested, including the restrictions that would apply. In case of NSMBW, the filesizes would be allowed to quadruple in size, while games that use an entire DVD5 could still double in size.
Btw, I've had the idea to prioritise smaller files over larger files, so that smaller files get more in relation to larger files.
That feature should probably be marked as experimental until the loading times were tested (with/without SUDTR). They could turn out to be awfully slow, or almost unchanged, hard to say. Would it be possible to add the feature to an unofficial version instead of the dev versions? And when tested positively, it should probably be hidden away as much as possible (Settings/Advancd) and labled as "Live Testing" or something similar.
(I've seen the NSMBW intro 5000 times perhaps, that should be enough for a lifetime
)
What's the use of "Null" as video backend?