Load and unload music files as needed

[mardy]

When VVVVVV is run on devices (such as the Nintendo Wii) that are memory costrained, it's not possible to load all the music files at startup.

Therefore, change the MusicTrack contructor to only save the RWops structure, and load the music data only when Play() gets called. Also, when a song start playing we do unload the previous one.

I tested this on the Nintendo Wii and it works fine there, I got to change several songs and everything seems to work fine. But I don't know if there are some corner cases I should pay more attention to.

Legal Stuff:

By submitting this pull request, I confirm that...

• My changes may be used in a future commercial release of VVVVVV
• I will be credited in a CONTRIBUTORS file and the "GitHub Friends"
  section of the credits for all of said releases, but will NOT be compensated
  for these changes unless there is a prior written agreement

[InfoTeddy]

Hi, sorry this wasn't reviewed sooner.

Immediately after this PR was open, concerns were brought up in the VVVVVV Discord about this being unnecessary if not harmful for PC, for both HDDs (load times every time a track is played) and SSDs (unnecessary writes to disk because of access times). Terry commented that this might be useful as a #ifdef for platforms that need it.

So as it is right now, this won't be merged.

[mardy]

Immediately after this PR was open, concerns were brought up in the VVVVVV Discord about this being unnecessary if not harmful for PC, for both HDDs (load times every time a track is played) and SSDs (unnecessary writes to disk because of access times). Terry commented that this might be useful as a #ifdef for platforms that need it.

Yes, there's a small delay when the track changes, but even on a slow machine such as the Wii it's quite bearable. As for the access times, that should not be a concern for the game, but rather for the OS: files are opened all the time, and VVVVVV changes song much more rarely than other programs access the disk, so we shouldn't worry about that.

I'll refactor the code so that the decision can be controlled by an #ifdef anyway, since that shouldn't be hard.

[Daaaav]

I think it's not so much casual playing that would be affected by it, but:

• For speedrunners, if the game suddenly freezes for a split second in places that it didn't before, it could be bad (especially if it's inconsistent)

• Custom levels can do very creative things, and may sometimes change the song very frequently, or rely on certain things to be kept in sync.

• Similarly, it has been mentioned that the ability to read data from disk on command could be abused by custom levels to wear out the drive as much as possible (though I don't know if reads wear out SSDs, I thought it was just writes. I might be wrong though)

[InfoTeddy]

(though I don't know if reads wear out SSDs, I thought it was just writes)

If access times are enabled, they can. Access times being enabled means that even reading a file updates the access time, which is a write to disk.

[Daaaav]

In theory we could make it so that if the RAM is sufficient, we don't discard the old song...

[mardy]

Hi! I updated the branch. I'm not using an ifdef, but instead I'm activating the on-demand loading and unloading of music only if the music is loaded from loose files. I was told that the "loose files" option was added exactly for the purpose of lowering the memory pressure on RAM-limited machines, so it seems reasonable to bind the logic to that factor.