mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-12-23 10:09:43 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/Music.cpp

554 lines
12 KiB
C++
Raw Normal View History

Clean up and prevent unnecessary qualifiers to self By "unnecessary qualifiers to self", I mean something like using the 'game.' qualifier for a variable on the Game class when you're inside a function on the Game class itself. This patch is to enforce consistency as most of the code doesn't have these unnecessary qualifiers. To prevent further unnecessary qualifiers to self, I made it so the extern in each header file can be omitted by using a define. That way, if someone writes something referring to 'game.' on a Game function, there will be a compile error. However, if you really need to have a reference to the global name, and you're within the same .cpp file as the implementation of that object, you can just do the extern at the function-level. A good example of this is editorinput()/editorrender()/editorlogic() in editor.cpp. In my opinion, they should probably be split off into their own separate file because editor.cpp is getting way too big, but this will do for now.
2020-09-28 04:15:06 +02:00
#define MUSIC_DEFINITION
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "Music.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include <SDL.h>
Remove data/ from track name list, refactor music loading, and support loose ogg music (these should be separate commits but they're annoying to split after the fact, oh well)
2020-07-30 23:06:07 +02:00
#include <physfsrwops.h>
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "BinaryBlob.h"
Factor fade amount calculation to separate function This makes it so to reuse this code, we don't have to copy-paste it. Additionally, I added a check for the milliseconds being 0, to avoid a division by zero. Logically and mathematically, if the fade amount is 0 milliseconds, then that means the fade should happen instantly - however, dividing by zero is undefined (both in math and in C/C++), so this check needs to be added.
2021-04-02 21:02:01 +02:00
#include "Game.h"
Replace main game music with music area map The main game used a set of copy-pasted code to set the music of each area. There WAS some redundancy built-in, but only three rooms in each direction from the entrance of a zone. Given this, it's completely possible for players to mismatch the music of the area and level. In fact, it's easy to do it even on accident, especially since 2.3 now lets you quicksave and quit during cutscenes. Just play a cutscene that has Pause music, then quicksave, quit, and reload. Also some other accidental ways that I've forgotten about. To fix this, I've done what mapclass has and made an areamap. Except for music. This map is the map of the track number of every single room, except for three special cases: -1 for do nothing and don't change music (usually because multiple different tracks can be played in this room), -2 for Tower music (needs to be track 2 or 9 depending on Flip Mode), and -3 for the start of Space Station 2 (track 1 in time trials, track 4 otherwise). I've thoroughly tested this areamap by playing through the game and entering every single room. Additionally I've also thoroughly tested all special cases (entering the Ship through the teleporter or main entrance, using the Ship's jukebox, the Tower in Flip Mode and regular mode, and the start of Space Station 2 in time trial and in regular mode). Closes #449.
2021-05-12 04:59:02 +02:00
#include "Graphics.h"
Un-fix using-PPPPPP-while-MMMMMM-present for custom levels As discussed earlier, some custom levels have taken advantage of the fact that songs 0 and 7 loop and also fade in when using PPPPPP while having an mmmmmm.vvv file present.
2020-04-04 00:37:59 +02:00
#include "Map.h"
Replace main game music with music area map The main game used a set of copy-pasted code to set the music of each area. There WAS some redundancy built-in, but only three rooms in each direction from the entrance of a zone. Given this, it's completely possible for players to mismatch the music of the area and level. In fact, it's easy to do it even on accident, especially since 2.3 now lets you quicksave and quit during cutscenes. Just play a cutscene that has Pause music, then quicksave, quit, and reload. Also some other accidental ways that I've forgotten about. To fix this, I've done what mapclass has and made an areamap. Except for music. This map is the map of the track number of every single room, except for three special cases: -1 for do nothing and don't change music (usually because multiple different tracks can be played in this room), -2 for Tower music (needs to be track 2 or 9 depending on Flip Mode), and -3 for the start of Space Station 2 (track 1 in time trials, track 4 otherwise). I've thoroughly tested this areamap by playing through the game and entering every single room. Additionally I've also thoroughly tested all special cases (entering the Ship through the teleporter or main entrance, using the Ship's jukebox, the Tower in Flip Mode and regular mode, and the start of Space Station 2 in time trial and in regular mode). Closes #449.
2021-05-12 04:59:02 +02:00
#include "Script.h"
Remove unnecessary includes from header files Including a header file inside another header file means a bunch of files are going to be unnecessarily recompiled whenever that inner header file is changed. So I minimized the amount of header files included in a header file, and only included the ones that were necessary (system includes don't count, I'm only talking about includes from within this project). Then the includes are only in the .cpp files themselves. This also minimizes problems such as a NO_CUSTOM_LEVELS build failing because some file depended on an include that got included in editor.h, which is another benefit of removing unnecessary includes from header files.
2020-07-19 21:05:41 +02:00
#include "UtilityClass.h"
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
#include "Vlogging.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
musicclass::musicclass(void)
Don't reset entire musicclass when mounting and unmounting assets musicclass::init() re-initializes every attribute of musicclass unnecessarily, when initialization should be put in a constructor instead. This is bad, because music.init() gets called whenever we enter and exit a custom level that has assets. Otherwise, this would result in a bug where music.usingmmmmmm would be reset, causing you to revert to PPPPPP on the title screen whenever you enter a level with MMMMMM selected and exit it. This also causes a confusing desync between game.usingmmmmmm and music.usingmmmmmm since the values of the two variables are now different (these duplicate variables should probably be removed, too, and a lot of other duplicate variables like these exist, too, which are a real headache). Which means despite MMMMMM playing on the title screen, exiting the game and re-launching it will play PPPPPP instead. What's even more is that going to game options and switching to PPPPPP will play PPPPPP, but afterwards launching and re-entering will play MMMMMM. Again, having duplicate variables is very bad, and should probably be fixed, but that's a separate patch.
2020-11-13 00:55:58 +01:00
{
safeToProcessMusic= false;
m_doFadeInVol = false;
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
m_doFadeOutVol = false;
musicVolume = 0;
Don't reset entire musicclass when mounting and unmounting assets musicclass::init() re-initializes every attribute of musicclass unnecessarily, when initialization should be put in a constructor instead. This is bad, because music.init() gets called whenever we enter and exit a custom level that has assets. Otherwise, this would result in a bug where music.usingmmmmmm would be reset, causing you to revert to PPPPPP on the title screen whenever you enter a level with MMMMMM selected and exit it. This also causes a confusing desync between game.usingmmmmmm and music.usingmmmmmm since the values of the two variables are now different (these duplicate variables should probably be removed, too, and a lot of other duplicate variables like these exist, too, which are a real headache). Which means despite MMMMMM playing on the title screen, exiting the game and re-launching it will play PPPPPP instead. What's even more is that going to game options and switching to PPPPPP will play PPPPPP, but afterwards launching and re-entering will play MMMMMM. Again, having duplicate variables is very bad, and should probably be fixed, but that's a separate patch.
2020-11-13 00:55:58 +01:00
Add music and sound volume config options This adds <musicvolume> and <soundvolume> tags to unlock.vvv and settings.vvv, so users' volume preferences will be persistent across game sessions. This does not add the user interface to change them from in-game; the next commit will do that.
2021-04-12 02:41:46 +02:00
user_music_volume = USER_VOLUME_MAX;
user_sound_volume = USER_VOLUME_MAX;
Don't reset entire musicclass when mounting and unmounting assets musicclass::init() re-initializes every attribute of musicclass unnecessarily, when initialization should be put in a constructor instead. This is bad, because music.init() gets called whenever we enter and exit a custom level that has assets. Otherwise, this would result in a bug where music.usingmmmmmm would be reset, causing you to revert to PPPPPP on the title screen whenever you enter a level with MMMMMM selected and exit it. This also causes a confusing desync between game.usingmmmmmm and music.usingmmmmmm since the values of the two variables are now different (these duplicate variables should probably be removed, too, and a lot of other duplicate variables like these exist, too, which are a real headache). Which means despite MMMMMM playing on the title screen, exiting the game and re-launching it will play PPPPPP instead. What's even more is that going to game options and switching to PPPPPP will play PPPPPP, but afterwards launching and re-entering will play MMMMMM. Again, having duplicate variables is very bad, and should probably be fixed, but that's a separate patch.
2020-11-13 00:55:58 +01:00
currentsong = 0;
nicechange = -1;
nicefade = false;
quick_fade = true;
usingmmmmmm = false;
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void musicclass::init(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Revert "Add destructor for SoundTrack/MusicTrack (and explicitly define move constructor to prevent double-free)" This reverts commit 2f760af4394b3279716e78ee17d8414f860b295e.
2020-06-07 21:49:18 +02:00
soundTracks.push_back(SoundTrack( "sounds/jump.wav" ));
soundTracks.push_back(SoundTrack( "sounds/jump2.wav" ));
soundTracks.push_back(SoundTrack( "sounds/hurt.wav" ));
soundTracks.push_back(SoundTrack( "sounds/souleyeminijingle.wav" ));
soundTracks.push_back(SoundTrack( "sounds/coin.wav" ));
soundTracks.push_back(SoundTrack( "sounds/save.wav" ));
soundTracks.push_back(SoundTrack( "sounds/crumble.wav" ));
soundTracks.push_back(SoundTrack( "sounds/vanish.wav" ));
soundTracks.push_back(SoundTrack( "sounds/blip.wav" ));
soundTracks.push_back(SoundTrack( "sounds/preteleport.wav" ));
soundTracks.push_back(SoundTrack( "sounds/teleport.wav" ));
soundTracks.push_back(SoundTrack( "sounds/crew1.wav" ));
soundTracks.push_back(SoundTrack( "sounds/crew2.wav" ));
soundTracks.push_back(SoundTrack( "sounds/crew3.wav" ));
soundTracks.push_back(SoundTrack( "sounds/crew4.wav" ));
soundTracks.push_back(SoundTrack( "sounds/crew5.wav" ));
soundTracks.push_back(SoundTrack( "sounds/crew6.wav" ));
soundTracks.push_back(SoundTrack( "sounds/terminal.wav" ));
soundTracks.push_back(SoundTrack( "sounds/gamesaved.wav" ));
soundTracks.push_back(SoundTrack( "sounds/crashing.wav" ));
soundTracks.push_back(SoundTrack( "sounds/blip2.wav" ));
soundTracks.push_back(SoundTrack( "sounds/countdown.wav" ));
soundTracks.push_back(SoundTrack( "sounds/go.wav" ));
soundTracks.push_back(SoundTrack( "sounds/crash.wav" ));
soundTracks.push_back(SoundTrack( "sounds/combine.wav" ));
soundTracks.push_back(SoundTrack( "sounds/newrecord.wav" ));
soundTracks.push_back(SoundTrack( "sounds/trophy.wav" ));
soundTracks.push_back(SoundTrack( "sounds/rescue.wav" ));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#ifdef VVV_COMPILEMUSIC
binaryBlob musicWriteBlob;
Remove data/ from track name list, refactor music loading, and support loose ogg music (these should be separate commits but they're annoying to split after the fact, oh well)
2020-07-30 23:06:07 +02:00
#define FOREACH_TRACK(blob, track_name) blob.AddFileToBinaryBlob("data/" track_name);
Refactor TRACK_NAMES to take in a blob parameter I'm going to introduce another binaryBlob object in to the mix, and I want to be able to re-use an existing FOREACH_TRACK #define without having to copy-paste it again. So, TRACK_NAMES now takes in a blob parameter, which will be passed to the temporary FOREACH_TRACK #define.
2021-02-16 01:38:10 +01:00
TRACK_NAMES(musicWriteBlob)
De-duplicate track names Instead of copy-pasting the entire list three times over, why not put it in an easy to use "X" macro?
2020-07-01 00:17:02 +02:00
#undef FOREACH_TRACK
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
musicWriteBlob.writeBinaryBlob("data/BinaryMusic.vvv");
Clear musicWriteBlob after writing BinaryMusic.vvv Since musicWriteBlob is a temporary object that gets destroyed at the end of musicclass::init(), in order to make sure we don't leak memory and lose all the pointers to the blocks we just allocated in musicWriteBlob, we need to call its clear() method after writing BinaryMusic.vvv.
2021-02-16 02:44:19 +01:00
musicWriteBlob.clear();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#endif
Account for extra tracks in musicclass::play() Since each soundtrack is no longer guaranteed to be 16, we'll have to account for their different lengths when playing music.
2020-07-01 02:08:37 +02:00
num_mmmmmm_tracks = 0;
num_pppppp_tracks = 0;
Separate musicReadBlob into mmmmmm_blob and pppppp_blob musicReadBlob was used for both MMMMMM and PPPPPP soundtracks. This causes a memory leak if you have mmmmmm.vvv installed, because the pointers holding each allocated block of MMMMMM would be lost when PPPPPP got loaded. Valgrind complains about this memory leak. This is in contrast to 2.2 and previous behavior, where musicReadBlob was only a temporary object instead of being held in musicclass. However, this wasn't really a memory leak (moreso something that just didn't get cleaned up when closing the game), but it did get turned into a leak when per-level assets mounting and unmounting got introduced in 2.3 (loading a level with custom assets after starting the game with an mmmmmm.vvv, or exiting out of a level that had an mmmmmm.vvv, would cause the game to leak memory). Leo recognized this, and moved musicReadBlob onto musicclass in a separate 2.3 PR, but either he didn't think about what was happening here too closely, or he didn't use Valgrind, because he forgot about the memory leak caused by re-using the same binaryBlob for PPPPPP and MMMMMM. So instead, just use two different binaryBlob objects for MMMMMM and PPPPPP. That way, no memory leaks happen.
2021-02-16 01:42:58 +01:00
if (!mmmmmm_blob.unPackBinary("mmmmmm.vvv"))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
if (pppppp_blob.unPackBinary("vvvvvvmusic.vvv"))
{
vlog_info("Loading music from PPPPPP blob...");
Remove data/ from track name list, refactor music loading, and support loose ogg music (these should be separate commits but they're annoying to split after the fact, oh well)
2020-07-30 23:06:07 +02:00
mmmmmm = false;
usingmmmmmm=false;
int index;
SDL_RWops* rw;
#define FOREACH_TRACK(blob, track_name) \
index = blob.getIndex("data/" track_name); \
rw = SDL_RWFromMem(blob.getAddress(index), blob.getSize(index)); \
musicTracks.push_back(MusicTrack( rw ));
TRACK_NAMES(pppppp_blob)
#undef FOREACH_TRACK
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
}
else
{
vlog_info("Loading music from loose files...");
Remove data/ from track name list, refactor music loading, and support loose ogg music (these should be separate commits but they're annoying to split after the fact, oh well)
2020-07-30 23:06:07 +02:00
SDL_RWops* rw;
#define FOREACH_TRACK(_, track_name) \
rw = PHYSFSRWOPS_openRead(track_name); \
musicTracks.push_back(MusicTrack( rw ));
TRACK_NAMES(_)
#undef FOREACH_TRACK
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("Loading PPPPPP and MMMMMM blobs...");
Remove data/ from track name list, refactor music loading, and support loose ogg music (these should be separate commits but they're annoying to split after the fact, oh well)
2020-07-30 23:06:07 +02:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
mmmmmm = true;
De-duplicate track names Instead of copy-pasting the entire list three times over, why not put it in an easy to use "X" macro?
2020-07-01 00:17:02 +02:00
int index;
SDL_RWops *rw;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Refactor TRACK_NAMES to take in a blob parameter I'm going to introduce another binaryBlob object in to the mix, and I want to be able to re-use an existing FOREACH_TRACK #define without having to copy-paste it again. So, TRACK_NAMES now takes in a blob parameter, which will be passed to the temporary FOREACH_TRACK #define.
2021-02-16 01:38:10 +01:00
#define FOREACH_TRACK(blob, track_name) \
Remove data/ from track name list, refactor music loading, and support loose ogg music (these should be separate commits but they're annoying to split after the fact, oh well)
2020-07-30 23:06:07 +02:00
index = blob.getIndex("data/" track_name); \
Refactor TRACK_NAMES to take in a blob parameter I'm going to introduce another binaryBlob object in to the mix, and I want to be able to re-use an existing FOREACH_TRACK #define without having to copy-paste it again. So, TRACK_NAMES now takes in a blob parameter, which will be passed to the temporary FOREACH_TRACK #define.
2021-02-16 01:38:10 +01:00
if (index >= 0 && index < blob.max_headers) \
Check index of tracks in musicclass::init() It's possible that musicReadBlob.getIndex() could return the sentinel value of -1 in case the header with that name is invalid, in which case we should simply not do anything. Otherwise it'll lead to segfaults. I opted to do the full bounds check just to be safe, too. For further safety, I hardcoded the max number of headers, 128, less, so 128 is copy-pasted less and in the future if it needs to be changed it'll only have to be changed in one place.
2020-08-14 11:02:16 +02:00
{ \
Replace all SDL_RWFromMem() with SDL_RWFromConstMem() Since we're not going to be writing to any of these RWops, we might as well just ensure that we don't by using SDL_RWFromConstMem().
2021-02-23 05:21:12 +01:00
rw = SDL_RWFromConstMem(blob.getAddress(index), blob.getSize(index)); \
Check `rw` in musicclass::init() It's possible that SDL_RWFromMem could return NULL, and if this is the case, then we really shouldn't be passing it to MusicTrack().
2020-08-14 11:23:41 +02:00
if (rw == NULL) \
{ \
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Unable to read music file header: %s", SDL_GetError()); \
Check `rw` in musicclass::init() It's possible that SDL_RWFromMem could return NULL, and if this is the case, then we really shouldn't be passing it to MusicTrack().
2020-08-14 11:23:41 +02:00
} \
else \
{ \
musicTracks.push_back(MusicTrack( rw )); \
} \
Check index of tracks in musicclass::init() It's possible that musicReadBlob.getIndex() could return the sentinel value of -1 in case the header with that name is invalid, in which case we should simply not do anything. Otherwise it'll lead to segfaults. I opted to do the full bounds check just to be safe, too. For further safety, I hardcoded the max number of headers, 128, less, so 128 is copy-pasted less and in the future if it needs to be changed it'll only have to be changed in one place.
2020-08-14 11:02:16 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Separate musicReadBlob into mmmmmm_blob and pppppp_blob musicReadBlob was used for both MMMMMM and PPPPPP soundtracks. This causes a memory leak if you have mmmmmm.vvv installed, because the pointers holding each allocated block of MMMMMM would be lost when PPPPPP got loaded. Valgrind complains about this memory leak. This is in contrast to 2.2 and previous behavior, where musicReadBlob was only a temporary object instead of being held in musicclass. However, this wasn't really a memory leak (moreso something that just didn't get cleaned up when closing the game), but it did get turned into a leak when per-level assets mounting and unmounting got introduced in 2.3 (loading a level with custom assets after starting the game with an mmmmmm.vvv, or exiting out of a level that had an mmmmmm.vvv, would cause the game to leak memory). Leo recognized this, and moved musicReadBlob onto musicclass in a separate 2.3 PR, but either he didn't think about what was happening here too closely, or he didn't use Valgrind, because he forgot about the memory leak caused by re-using the same binaryBlob for PPPPPP and MMMMMM. So instead, just use two different binaryBlob objects for MMMMMM and PPPPPP. That way, no memory leaks happen.
2021-02-16 01:42:58 +01:00
TRACK_NAMES(mmmmmm_blob)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Check index of tracks in musicclass::init() It's possible that musicReadBlob.getIndex() could return the sentinel value of -1 in case the header with that name is invalid, in which case we should simply not do anything. Otherwise it'll lead to segfaults. I opted to do the full bounds check just to be safe, too. For further safety, I hardcoded the max number of headers, 128, less, so 128 is copy-pasted less and in the future if it needs to be changed it'll only have to be changed in one place.
2020-08-14 11:02:16 +02:00
num_mmmmmm_tracks += musicTracks.size();
Account for extra tracks in musicclass::play() Since each soundtrack is no longer guaranteed to be 16, we'll have to account for their different lengths when playing music.
2020-07-01 02:08:37 +02:00
Refactor extra binary blob tracks to not use STL data marshalling Just like I refactored text splitting to no longer use std::vectors, std::strings, or temporary heap allocations, decreasing memory usage and improving performance; there's no reason to use a temporary heap-allocated std::vector to grab all extra binary blob indices, when instead the iteration can just be more immediate. Instead, what I've done is replaced binaryBlob::getExtra() with binaryBlob::nextExtra(), which takes in a pointer to an index variable, and will increment the index variable until it reaches an extra track. After the caller processes the extra track, it is the caller's responsibility to increment the variable again before passing it back to getExtra(). This avoids all heap allocations and brings down the memory usage of processing extra tracks.
2021-02-18 08:48:41 +01:00
size_t index_ = 0;
while (mmmmmm_blob.nextExtra(&index_))
Parse extra headers from binary blob Not just the ones that contain specific names.
2020-07-01 00:35:50 +02:00
{
Replace all SDL_RWFromMem() with SDL_RWFromConstMem() Since we're not going to be writing to any of these RWops, we might as well just ensure that we don't by using SDL_RWFromConstMem().
2021-02-23 05:21:12 +01:00
rw = SDL_RWFromConstMem(mmmmmm_blob.getAddress(index_), mmmmmm_blob.getSize(index_));
Parse extra headers from binary blob Not just the ones that contain specific names.
2020-07-01 00:35:50 +02:00
musicTracks.push_back(MusicTrack( rw ));
Account for extra tracks in musicclass::play() Since each soundtrack is no longer guaranteed to be 16, we'll have to account for their different lengths when playing music.
2020-07-01 02:08:37 +02:00
num_mmmmmm_tracks++;
Refactor extra binary blob tracks to not use STL data marshalling Just like I refactored text splitting to no longer use std::vectors, std::strings, or temporary heap allocations, decreasing memory usage and improving performance; there's no reason to use a temporary heap-allocated std::vector to grab all extra binary blob indices, when instead the iteration can just be more immediate. Instead, what I've done is replaced binaryBlob::getExtra() with binaryBlob::nextExtra(), which takes in a pointer to an index variable, and will increment the index variable until it reaches an extra track. After the caller processes the extra track, it is the caller's responsibility to increment the variable again before passing it back to getExtra(). This avoids all heap allocations and brings down the memory usage of processing extra tracks.
2021-02-18 08:48:41 +01:00
index_++;
Parse extra headers from binary blob Not just the ones that contain specific names.
2020-07-01 00:35:50 +02:00
}
Separate musicReadBlob into mmmmmm_blob and pppppp_blob musicReadBlob was used for both MMMMMM and PPPPPP soundtracks. This causes a memory leak if you have mmmmmm.vvv installed, because the pointers holding each allocated block of MMMMMM would be lost when PPPPPP got loaded. Valgrind complains about this memory leak. This is in contrast to 2.2 and previous behavior, where musicReadBlob was only a temporary object instead of being held in musicclass. However, this wasn't really a memory leak (moreso something that just didn't get cleaned up when closing the game), but it did get turned into a leak when per-level assets mounting and unmounting got introduced in 2.3 (loading a level with custom assets after starting the game with an mmmmmm.vvv, or exiting out of a level that had an mmmmmm.vvv, would cause the game to leak memory). Leo recognized this, and moved musicReadBlob onto musicclass in a separate 2.3 PR, but either he didn't think about what was happening here too closely, or he didn't use Valgrind, because he forgot about the memory leak caused by re-using the same binaryBlob for PPPPPP and MMMMMM. So instead, just use two different binaryBlob objects for MMMMMM and PPPPPP. That way, no memory leaks happen.
2021-02-16 01:42:58 +01:00
bool ohCrap = pppppp_blob.unPackBinary("vvvvvvmusic.vvv");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
SDL_assert(ohCrap && "Music not found!");
Separate musicReadBlob into mmmmmm_blob and pppppp_blob musicReadBlob was used for both MMMMMM and PPPPPP soundtracks. This causes a memory leak if you have mmmmmm.vvv installed, because the pointers holding each allocated block of MMMMMM would be lost when PPPPPP got loaded. Valgrind complains about this memory leak. This is in contrast to 2.2 and previous behavior, where musicReadBlob was only a temporary object instead of being held in musicclass. However, this wasn't really a memory leak (moreso something that just didn't get cleaned up when closing the game), but it did get turned into a leak when per-level assets mounting and unmounting got introduced in 2.3 (loading a level with custom assets after starting the game with an mmmmmm.vvv, or exiting out of a level that had an mmmmmm.vvv, would cause the game to leak memory). Leo recognized this, and moved musicReadBlob onto musicclass in a separate 2.3 PR, but either he didn't think about what was happening here too closely, or he didn't use Valgrind, because he forgot about the memory leak caused by re-using the same binaryBlob for PPPPPP and MMMMMM. So instead, just use two different binaryBlob objects for MMMMMM and PPPPPP. That way, no memory leaks happen.
2021-02-16 01:42:58 +01:00
TRACK_NAMES(pppppp_blob)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
De-duplicate track names Instead of copy-pasting the entire list three times over, why not put it in an easy to use "X" macro?
2020-07-01 00:17:02 +02:00
#undef FOREACH_TRACK
Remove data/ from track name list, refactor music loading, and support loose ogg music (these should be separate commits but they're annoying to split after the fact, oh well)
2020-07-30 23:06:07 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Check index of tracks in musicclass::init() It's possible that musicReadBlob.getIndex() could return the sentinel value of -1 in case the header with that name is invalid, in which case we should simply not do anything. Otherwise it'll lead to segfaults. I opted to do the full bounds check just to be safe, too. For further safety, I hardcoded the max number of headers, 128, less, so 128 is copy-pasted less and in the future if it needs to be changed it'll only have to be changed in one place.
2020-08-14 11:02:16 +02:00
num_pppppp_tracks += musicTracks.size() - num_mmmmmm_tracks;
Account for extra tracks in musicclass::play() Since each soundtrack is no longer guaranteed to be 16, we'll have to account for their different lengths when playing music.
2020-07-01 02:08:37 +02:00
Remove data/ from track name list, refactor music loading, and support loose ogg music (these should be separate commits but they're annoying to split after the fact, oh well)
2020-07-30 23:06:07 +02:00
SDL_RWops* rw;
Refactor extra binary blob tracks to not use STL data marshalling Just like I refactored text splitting to no longer use std::vectors, std::strings, or temporary heap allocations, decreasing memory usage and improving performance; there's no reason to use a temporary heap-allocated std::vector to grab all extra binary blob indices, when instead the iteration can just be more immediate. Instead, what I've done is replaced binaryBlob::getExtra() with binaryBlob::nextExtra(), which takes in a pointer to an index variable, and will increment the index variable until it reaches an extra track. After the caller processes the extra track, it is the caller's responsibility to increment the variable again before passing it back to getExtra(). This avoids all heap allocations and brings down the memory usage of processing extra tracks.
2021-02-18 08:48:41 +01:00
size_t index_ = 0;
while (pppppp_blob.nextExtra(&index_))
Parse extra headers from binary blob Not just the ones that contain specific names.
2020-07-01 00:35:50 +02:00
{
Replace all SDL_RWFromMem() with SDL_RWFromConstMem() Since we're not going to be writing to any of these RWops, we might as well just ensure that we don't by using SDL_RWFromConstMem().
2021-02-23 05:21:12 +01:00
rw = SDL_RWFromConstMem(pppppp_blob.getAddress(index_), pppppp_blob.getSize(index_));
Parse extra headers from binary blob Not just the ones that contain specific names.
2020-07-01 00:35:50 +02:00
musicTracks.push_back(MusicTrack( rw ));
Account for extra tracks in musicclass::play() Since each soundtrack is no longer guaranteed to be 16, we'll have to account for their different lengths when playing music.
2020-07-01 02:08:37 +02:00
num_pppppp_tracks++;
Refactor extra binary blob tracks to not use STL data marshalling Just like I refactored text splitting to no longer use std::vectors, std::strings, or temporary heap allocations, decreasing memory usage and improving performance; there's no reason to use a temporary heap-allocated std::vector to grab all extra binary blob indices, when instead the iteration can just be more immediate. Instead, what I've done is replaced binaryBlob::getExtra() with binaryBlob::nextExtra(), which takes in a pointer to an index variable, and will increment the index variable until it reaches an extra track. After the caller processes the extra track, it is the caller's responsibility to increment the variable again before passing it back to getExtra(). This avoids all heap allocations and brings down the memory usage of processing extra tracks.
2021-02-18 08:48:41 +01:00
index_++;
Parse extra headers from binary blob Not just the ones that contain specific names.
2020-07-01 00:35:50 +02:00
}
Fix resumemusic/musicfadein not working It seems like they were unfinished. This commit makes them properly work. When a track is stopped with stopmusic() or musicfadeout(), resumemusic() will resume from where the track stopped. musicfadein() does the same but does it with a gradual fade instead of suddenly playing it at full volume. I changed several interfaces around for this. First, setting currentsong to -1 when music is stopped is handled in the hook callback that gets called by SDL_mixer whenever the music stops. Otherwise, it'd be problematic if currentsong was set to -1 when the song starts fading out instead of when the song actually ends. Also, music.play() has a few optional arguments now, to reduce the copying-and-pasting of music code. Lastly, we have to roll our own tracker of music length by using SDL_GetPerformanceCounter(), because there's no way to get the music position if a song fades out. (We could implicitly keep the music position if we abruptly stopped the song using Mix_PauseMusic(), and resume it using Mix_ResumeMusic(), but ignoring the fact that those two functions are also used on the unfocus-pause (which, as it turns out, is basically a non-issue because the unfocus-pause can use some other functions), there's no equivalent for fading out, i.e. there's no "fade out and pause when it fully fades out" function in SDL_mixer.) And then we have to account for the unfocus-pause in our manual tracker. Other than that, these commands are now fully functional.
2020-06-27 10:31:09 +02:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void musicclass::destroy(void)
Move musicclass cleanup to separate function musicclass::destroy() This removes the music cleanup code from musicclass::init(), and requires that we also call destroy() in Graphics::reloadresources(). This is because we'll need to re-use the musicclass cleanup code elsewhere, and we don't want to copy-paste the cleanup code. Or at least, I don't (but I'm not a game dev, game devs copy-paste all the friggin' time).
2021-02-16 01:24:21 +01:00
{
for (size_t i = 0; i < soundTracks.size(); ++i)
{
Mix_FreeChunk(soundTracks[i].sound);
}
soundTracks.clear();
// Before we free all the music: stop playing music, else SDL2_mixer
// will call SDL_Delay() if we are fading, resulting in no-draw frames
Mix_HaltMusic();
for (size_t i = 0; i < musicTracks.size(); ++i)
{
Mix_FreeMusic(musicTracks[i].m_music);
}
musicTracks.clear();
Separate musicReadBlob into mmmmmm_blob and pppppp_blob musicReadBlob was used for both MMMMMM and PPPPPP soundtracks. This causes a memory leak if you have mmmmmm.vvv installed, because the pointers holding each allocated block of MMMMMM would be lost when PPPPPP got loaded. Valgrind complains about this memory leak. This is in contrast to 2.2 and previous behavior, where musicReadBlob was only a temporary object instead of being held in musicclass. However, this wasn't really a memory leak (moreso something that just didn't get cleaned up when closing the game), but it did get turned into a leak when per-level assets mounting and unmounting got introduced in 2.3 (loading a level with custom assets after starting the game with an mmmmmm.vvv, or exiting out of a level that had an mmmmmm.vvv, would cause the game to leak memory). Leo recognized this, and moved musicReadBlob onto musicclass in a separate 2.3 PR, but either he didn't think about what was happening here too closely, or he didn't use Valgrind, because he forgot about the memory leak caused by re-using the same binaryBlob for PPPPPP and MMMMMM. So instead, just use two different binaryBlob objects for MMMMMM and PPPPPP. That way, no memory leaks happen.
2021-02-16 01:42:58 +01:00
pppppp_blob.clear();
mmmmmm_blob.clear();
Move musicclass cleanup to separate function musicclass::destroy() This removes the music cleanup code from musicclass::init(), and requires that we also call destroy() in Graphics::reloadresources(). This is because we'll need to re-use the musicclass cleanup code elsewhere, and we don't want to copy-paste the cleanup code. Or at least, I don't (but I'm not a game dev, game devs copy-paste all the friggin' time).
2021-02-16 01:24:21 +01:00
}
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
void musicclass::play(int t)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Account for extra tracks in musicclass::play() Since each soundtrack is no longer guaranteed to be 16, we'll have to account for their different lengths when playing music.
2020-07-01 02:08:37 +02:00
if (mmmmmm && usingmmmmmm)
{
Check divisor in musicclass::play() Previously, it was assuming that the number of PPPPPP/MMMMMM tracks would always be 16, since if that wasn't the case... then the game would rudely and abruptly segfault when attempting to load the file. Huh. But now that the game properly deals with invalid headers, it's possible for the number of tracks to be 0. So I'll need to remove this assumption.
2020-08-14 11:15:09 +02:00
// Don't conjoin this if-statement with the above one...
if (num_mmmmmm_tracks > 0)
{
t %= num_mmmmmm_tracks;
}
Account for extra tracks in musicclass::play() Since each soundtrack is no longer guaranteed to be 16, we'll have to account for their different lengths when playing music.
2020-07-01 02:08:37 +02:00
}
Check divisor in musicclass::play() Previously, it was assuming that the number of PPPPPP/MMMMMM tracks would always be 16, since if that wasn't the case... then the game would rudely and abruptly segfault when attempting to load the file. Huh. But now that the game properly deals with invalid headers, it's possible for the number of tracks to be 0. So I'll need to remove this assumption.
2020-08-14 11:15:09 +02:00
else if (num_pppppp_tracks > 0)
Account for extra tracks in musicclass::play() Since each soundtrack is no longer guaranteed to be 16, we'll have to account for their different lengths when playing music.
2020-07-01 02:08:37 +02:00
{
t %= num_pppppp_tracks;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Fix whitespace inconsistency in musicclass::play() Spaces are used around operators and keywords accordingly, and blank lines are used to visually separate lines of code from each other.
2021-01-04 08:20:35 +01:00
if (mmmmmm && !usingmmmmmm)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Account for extra tracks in musicclass::play() Since each soundtrack is no longer guaranteed to be 16, we'll have to account for their different lengths when playing music.
2020-07-01 02:08:37 +02:00
t += num_mmmmmm_tracks;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Fix whitespace inconsistency in musicclass::play() Spaces are used around operators and keywords accordingly, and blank lines are used to visually separate lines of code from each other.
2021-01-04 08:20:35 +01:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
safeToProcessMusic = true;
Fix whitespace inconsistency in musicclass::play() Spaces are used around operators and keywords accordingly, and blank lines are used to visually separate lines of code from each other.
2021-01-04 08:20:35 +01:00
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
if (currentsong == t && !m_doFadeOutVol)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Invert currentsong check and un-nest rest of function This removes an indentation level, and makes it easier to reason about the function since you essentially now view it as the function returning right there.
2021-01-04 08:22:00 +01:00
return;
}
Invert t comparison with -1 and un-nest rest of function This is also another conditional where the rest of the function is nested. Furthermore, in order to not repeat ourselves, I've also decided to unconditionally assign currentsong to t, because if t is -1 currentsong gets assigned to -1 anyway - so it's the same thing, but it's much easier to see and think about.
2021-01-04 08:23:46 +01:00
currentsong = t;
Unindent musicclass::play() from previous two commits As always, the actual unindenting happens in a separate commit in order to minimize diff noise.
2021-01-04 08:26:05 +01:00
if (t == -1)
{
return;
}
if (!INBOUNDS_VEC(t, musicTracks))
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("play() out-of-bounds!");
Unindent musicclass::play() from previous two commits As always, the actual unindenting happens in a separate commit in order to minimize diff noise.
2021-01-04 08:26:05 +01:00
currentsong = -1;
return;
}
Reset fade booleans when starting music This fixes issues with music playing, only for it to fade out afterwards. This happened if tracks 0 or 7 were played after fading out, because playing other tracks reset the fade booleans (by calling a fade-in), but not tracks 0 or 7.
2021-04-28 01:57:32 +02:00
m_doFadeInVol = false;
m_doFadeOutVol = false;
Unindent musicclass::play() from previous two commits As always, the actual unindenting happens in a separate commit in order to minimize diff noise.
2021-01-04 08:26:05 +01:00
if (currentsong == 0 || currentsong == 7 || (!map.custommode && (currentsong == 0+num_mmmmmm_tracks || currentsong == 7+num_mmmmmm_tracks)))
{
// Level Complete theme, no fade in or repeat
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
if (Mix_PlayMusic(musicTracks[t].m_music, 0) == -1)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Mix_PlayMusic: %s", Mix_GetError());
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
}
else
{
musicVolume = MIX_MAX_VOLUME;
Call Mix_VolumeMusic() when playing tracks 0 and 7 This fixes issues where they would be silent for 1 frame due to frame ordering, resulting in a weird-sounding beginning of these tracks due to a lack of attack (in the musical sense). This is similar to the issue where tracks fading in would suddenly be loud for 1 frame, again due to frame ordering.
2021-04-28 01:59:01 +02:00
Mix_VolumeMusic(musicVolume);
Invert t comparison with -1 and un-nest rest of function This is also another conditional where the rest of the function is nested. Furthermore, in order to not repeat ourselves, I've also decided to unconditionally assign currentsong to t, because if t is -1 currentsong gets assigned to -1 anyway - so it's the same thing, but it's much easier to see and think about.
2021-01-04 08:23:46 +01:00
}
Unindent musicclass::play() from previous two commits As always, the actual unindenting happens in a separate commit in order to minimize diff noise.
2021-01-04 08:26:05 +01:00
}
else
{
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
if (m_doFadeOutVol)
Unindent musicclass::play() from previous two commits As always, the actual unindenting happens in a separate commit in order to minimize diff noise.
2021-01-04 08:26:05 +01:00
{
// We're already fading out
nicechange = t;
nicefade = true;
currentsong = -1;
Fix whitespace inconsistency in musicclass::play() Spaces are used around operators and keywords accordingly, and blank lines are used to visually separate lines of code from each other.
2021-01-04 08:20:35 +01:00
Unindent musicclass::play() from previous two commits As always, the actual unindenting happens in a separate commit in order to minimize diff noise.
2021-01-04 08:26:05 +01:00
if (quick_fade)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
fadeMusicVolumeOut(500); // fade out quicker
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Unindent musicclass::play() from previous two commits As always, the actual unindenting happens in a separate commit in order to minimize diff noise.
2021-01-04 08:26:05 +01:00
quick_fade = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Unindent musicclass::play() from previous two commits As always, the actual unindenting happens in a separate commit in order to minimize diff noise.
2021-01-04 08:26:05 +01:00
}
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
else if (Mix_PlayMusic(musicTracks[t].m_music, -1) == -1)
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Mix_PlayMusic: %s", Mix_GetError());
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
}
else
Unindent musicclass::play() from previous two commits As always, the actual unindenting happens in a separate commit in order to minimize diff noise.
2021-01-04 08:26:05 +01:00
{
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
fadeMusicVolumeIn(3000);
Unindent musicclass::play() from previous two commits As always, the actual unindenting happens in a separate commit in order to minimize diff noise.
2021-01-04 08:26:05 +01:00
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
void musicclass::resume()
Fix resumemusic/musicfadein not working It seems like they were unfinished. This commit makes them properly work. When a track is stopped with stopmusic() or musicfadeout(), resumemusic() will resume from where the track stopped. musicfadein() does the same but does it with a gradual fade instead of suddenly playing it at full volume. I changed several interfaces around for this. First, setting currentsong to -1 when music is stopped is handled in the hook callback that gets called by SDL_mixer whenever the music stops. Otherwise, it'd be problematic if currentsong was set to -1 when the song starts fading out instead of when the song actually ends. Also, music.play() has a few optional arguments now, to reduce the copying-and-pasting of music code. Lastly, we have to roll our own tracker of music length by using SDL_GetPerformanceCounter(), because there's no way to get the music position if a song fades out. (We could implicitly keep the music position if we abruptly stopped the song using Mix_PauseMusic(), and resume it using Mix_ResumeMusic(), but ignoring the fact that those two functions are also used on the unfocus-pause (which, as it turns out, is basically a non-issue because the unfocus-pause can use some other functions), there's no equivalent for fading out, i.e. there's no "fade out and pause when it fully fades out" function in SDL_mixer.) And then we have to account for the unfocus-pause in our manual tracker. Other than that, these commands are now fully functional.
2020-06-27 10:31:09 +02:00
{
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
Mix_ResumeMusic();
}
Fix resumemusic/musicfadein not working It seems like they were unfinished. This commit makes them properly work. When a track is stopped with stopmusic() or musicfadeout(), resumemusic() will resume from where the track stopped. musicfadein() does the same but does it with a gradual fade instead of suddenly playing it at full volume. I changed several interfaces around for this. First, setting currentsong to -1 when music is stopped is handled in the hook callback that gets called by SDL_mixer whenever the music stops. Otherwise, it'd be problematic if currentsong was set to -1 when the song starts fading out instead of when the song actually ends. Also, music.play() has a few optional arguments now, to reduce the copying-and-pasting of music code. Lastly, we have to roll our own tracker of music length by using SDL_GetPerformanceCounter(), because there's no way to get the music position if a song fades out. (We could implicitly keep the music position if we abruptly stopped the song using Mix_PauseMusic(), and resume it using Mix_ResumeMusic(), but ignoring the fact that those two functions are also used on the unfocus-pause (which, as it turns out, is basically a non-issue because the unfocus-pause can use some other functions), there's no equivalent for fading out, i.e. there's no "fade out and pause when it fully fades out" function in SDL_mixer.) And then we have to account for the unfocus-pause in our manual tracker. Other than that, these commands are now fully functional.
2020-06-27 10:31:09 +02:00
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
void musicclass::resumefade(const int fadein_ms)
{
resume();
fadeMusicVolumeIn(fadein_ms);
Fix resumemusic/musicfadein not working It seems like they were unfinished. This commit makes them properly work. When a track is stopped with stopmusic() or musicfadeout(), resumemusic() will resume from where the track stopped. musicfadein() does the same but does it with a gradual fade instead of suddenly playing it at full volume. I changed several interfaces around for this. First, setting currentsong to -1 when music is stopped is handled in the hook callback that gets called by SDL_mixer whenever the music stops. Otherwise, it'd be problematic if currentsong was set to -1 when the song starts fading out instead of when the song actually ends. Also, music.play() has a few optional arguments now, to reduce the copying-and-pasting of music code. Lastly, we have to roll our own tracker of music length by using SDL_GetPerformanceCounter(), because there's no way to get the music position if a song fades out. (We could implicitly keep the music position if we abruptly stopped the song using Mix_PauseMusic(), and resume it using Mix_ResumeMusic(), but ignoring the fact that those two functions are also used on the unfocus-pause (which, as it turns out, is basically a non-issue because the unfocus-pause can use some other functions), there's no equivalent for fading out, i.e. there's no "fade out and pause when it fully fades out" function in SDL_mixer.) And then we have to account for the unfocus-pause in our manual tracker. Other than that, these commands are now fully functional.
2020-06-27 10:31:09 +02:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void musicclass::fadein(void)
Fix resumemusic/musicfadein not working It seems like they were unfinished. This commit makes them properly work. When a track is stopped with stopmusic() or musicfadeout(), resumemusic() will resume from where the track stopped. musicfadein() does the same but does it with a gradual fade instead of suddenly playing it at full volume. I changed several interfaces around for this. First, setting currentsong to -1 when music is stopped is handled in the hook callback that gets called by SDL_mixer whenever the music stops. Otherwise, it'd be problematic if currentsong was set to -1 when the song starts fading out instead of when the song actually ends. Also, music.play() has a few optional arguments now, to reduce the copying-and-pasting of music code. Lastly, we have to roll our own tracker of music length by using SDL_GetPerformanceCounter(), because there's no way to get the music position if a song fades out. (We could implicitly keep the music position if we abruptly stopped the song using Mix_PauseMusic(), and resume it using Mix_ResumeMusic(), but ignoring the fact that those two functions are also used on the unfocus-pause (which, as it turns out, is basically a non-issue because the unfocus-pause can use some other functions), there's no equivalent for fading out, i.e. there's no "fade out and pause when it fully fades out" function in SDL_mixer.) And then we have to account for the unfocus-pause in our manual tracker. Other than that, these commands are now fully functional.
2020-06-27 10:31:09 +02:00
{
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
resumefade(3000); // 3000 ms fadein
Fix resumemusic/musicfadein not working It seems like they were unfinished. This commit makes them properly work. When a track is stopped with stopmusic() or musicfadeout(), resumemusic() will resume from where the track stopped. musicfadein() does the same but does it with a gradual fade instead of suddenly playing it at full volume. I changed several interfaces around for this. First, setting currentsong to -1 when music is stopped is handled in the hook callback that gets called by SDL_mixer whenever the music stops. Otherwise, it'd be problematic if currentsong was set to -1 when the song starts fading out instead of when the song actually ends. Also, music.play() has a few optional arguments now, to reduce the copying-and-pasting of music code. Lastly, we have to roll our own tracker of music length by using SDL_GetPerformanceCounter(), because there's no way to get the music position if a song fades out. (We could implicitly keep the music position if we abruptly stopped the song using Mix_PauseMusic(), and resume it using Mix_ResumeMusic(), but ignoring the fact that those two functions are also used on the unfocus-pause (which, as it turns out, is basically a non-issue because the unfocus-pause can use some other functions), there's no equivalent for fading out, i.e. there's no "fade out and pause when it fully fades out" function in SDL_mixer.) And then we have to account for the unfocus-pause in our manual tracker. Other than that, these commands are now fully functional.
2020-06-27 10:31:09 +02:00
}
Add pause(), pauseef(), and resumeef() to musicclass musicclass already had a resume() function for music. These are just wrappers around the appropriate SDL_mixer functions, to avoid direct function calls to the mixer API. So if we ever need to do something with all callers of pausing and resuming in the future, or we switch to a different audio backend, the work is already done for us. Also it just looks cleaner to be calling our musicclass function instead of doing a direct API call to the mixer.
2021-04-02 21:07:19 +02:00
void musicclass::pause(void)
{
Mix_PauseMusic();
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void musicclass::haltdasmusik(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
/* Just pauses music. This is intended. */
pause();
Set currentsong to -1 when halting music This is 2.2 behavior, which I forgot to keep. Otherwise, if music has halted and you try to play the same track, it simply won't work, because the current song is the same as the song you're trying to play. This is what happened with the trinket scripts - the game halted music, then tried to play the same track. Fixes #712.
2021-04-12 18:27:04 +02:00
currentsong = -1;
Reset fade booleans when halting music This fixes the 2.2-and-below music blocking workaround not working in 2.3. The issue was that when the music got halted by the script, the fade volume would still be processing, silently being decremented in the background. So the script playing the track afterwards would make the game queue it (as it was called during the fade), but then the music is halted so the game would attempt to play it, but the fade is STILL happening so it wouldn't actually play it and would attempt to queue the track again. However, that queue gets discarded immediately afterwards because the music.play() call happened inside the code responsible for playing the queued music, and that code unconditionally clears the queue variables immediately after calling play(). So that's good to know - if the game queues a song, but fails to play it because of a fade, it's not going to immediately re-queue it and potentially get stuck in a loop of infinitely queueing the same song over and over again each frame. Anyways, the source of the problem is not resetting the fade booleans when halting music, so I've reset them. Fixes #701.
2021-04-12 20:39:55 +02:00
m_doFadeInVol = false;
m_doFadeOutVol = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void musicclass::silencedasmusik(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
musicVolume = 0;
}
Fix fade volume durations being incorrect The previous fade system used only one variable, the amount of volume to fade per frame. However, this variable was an integer, meaning any decimal portion would be truncated, and would lead to a longer fade duration than intended. The fade per volume is calculated by doing MIX_MAX_VOLUME / (fade_ms / game.get_timestep()). MIX_MAX_VOLUME is 128, and game.get_timestep() is usually 34, so a 3000 millisecond fade would be calculated as 128 / (3000 / 34). 3000 / 34 is 88.235..., but that gets truncated to 88, and then 128 / 88 becomes 1.454545..., which then gets truncated to 1. This essentially means 1 is added to or subtracted from the volume every frame, and given that the max volume is 128, this means that the fade lasts for 128 frames. Now, instead of the fade duration lasting 3 seconds, the fade now lasts for 128 frames, which is 128 * 34 / 1000 = 4.352 seconds long. This could be fixed using floats, but when you introduce floats, you now have 1.9999998 problems. For instance, I'm concerned about floating-point determinism issues. What I've done instead is switch the system to use four different variables instead: the start volume, the end volume, the total duration, and the duration completed so far (called the "step"). For every frame, the game interpolates which value should be used based on the step, the total duration, and the start and end volumes, and then adds the timestep to the step. This way, fades will be correctly timed, and we don't have potential determinism issues. Doing this also fixes inaccuracies with the game timestep changing during the fade, since the timestep is only used in the calculation once at the beginning in the previous system.
2021-04-28 01:37:16 +02:00
struct FadeState
Factor fade amount calculation to separate function This makes it so to reuse this code, we don't have to copy-paste it. Additionally, I added a check for the milliseconds being 0, to avoid a division by zero. Logically and mathematically, if the fade amount is 0 milliseconds, then that means the fade should happen instantly - however, dividing by zero is undefined (both in math and in C/C++), so this check needs to be added.
2021-04-02 21:02:01 +02:00
{
Fix fade volume durations being incorrect The previous fade system used only one variable, the amount of volume to fade per frame. However, this variable was an integer, meaning any decimal portion would be truncated, and would lead to a longer fade duration than intended. The fade per volume is calculated by doing MIX_MAX_VOLUME / (fade_ms / game.get_timestep()). MIX_MAX_VOLUME is 128, and game.get_timestep() is usually 34, so a 3000 millisecond fade would be calculated as 128 / (3000 / 34). 3000 / 34 is 88.235..., but that gets truncated to 88, and then 128 / 88 becomes 1.454545..., which then gets truncated to 1. This essentially means 1 is added to or subtracted from the volume every frame, and given that the max volume is 128, this means that the fade lasts for 128 frames. Now, instead of the fade duration lasting 3 seconds, the fade now lasts for 128 frames, which is 128 * 34 / 1000 = 4.352 seconds long. This could be fixed using floats, but when you introduce floats, you now have 1.9999998 problems. For instance, I'm concerned about floating-point determinism issues. What I've done instead is switch the system to use four different variables instead: the start volume, the end volume, the total duration, and the duration completed so far (called the "step"). For every frame, the game interpolates which value should be used based on the step, the total duration, and the start and end volumes, and then adds the timestep to the step. This way, fades will be correctly timed, and we don't have potential determinism issues. Doing this also fixes inaccuracies with the game timestep changing during the fade, since the timestep is only used in the calculation once at the beginning in the previous system.
2021-04-28 01:37:16 +02:00
int start_volume;
int end_volume;
int duration_ms;
int step_ms;
};
static struct FadeState fade;
enum FadeCode
{
Fade_continue,
Fade_finished
};
static enum FadeCode processmusicfade(struct FadeState* state, int* volume)
{
int range;
int new_volume;
if (state->duration_ms == 0 /* Fast path. */
|| state->start_volume == state->end_volume /* Fast path. */
|| state->step_ms >= state->duration_ms /* We're finished. */)
Factor fade amount calculation to separate function This makes it so to reuse this code, we don't have to copy-paste it. Additionally, I added a check for the milliseconds being 0, to avoid a division by zero. Logically and mathematically, if the fade amount is 0 milliseconds, then that means the fade should happen instantly - however, dividing by zero is undefined (both in math and in C/C++), so this check needs to be added.
2021-04-02 21:02:01 +02:00
{
Fix fade volume durations being incorrect The previous fade system used only one variable, the amount of volume to fade per frame. However, this variable was an integer, meaning any decimal portion would be truncated, and would lead to a longer fade duration than intended. The fade per volume is calculated by doing MIX_MAX_VOLUME / (fade_ms / game.get_timestep()). MIX_MAX_VOLUME is 128, and game.get_timestep() is usually 34, so a 3000 millisecond fade would be calculated as 128 / (3000 / 34). 3000 / 34 is 88.235..., but that gets truncated to 88, and then 128 / 88 becomes 1.454545..., which then gets truncated to 1. This essentially means 1 is added to or subtracted from the volume every frame, and given that the max volume is 128, this means that the fade lasts for 128 frames. Now, instead of the fade duration lasting 3 seconds, the fade now lasts for 128 frames, which is 128 * 34 / 1000 = 4.352 seconds long. This could be fixed using floats, but when you introduce floats, you now have 1.9999998 problems. For instance, I'm concerned about floating-point determinism issues. What I've done instead is switch the system to use four different variables instead: the start volume, the end volume, the total duration, and the duration completed so far (called the "step"). For every frame, the game interpolates which value should be used based on the step, the total duration, and the start and end volumes, and then adds the timestep to the step. This way, fades will be correctly timed, and we don't have potential determinism issues. Doing this also fixes inaccuracies with the game timestep changing during the fade, since the timestep is only used in the calculation once at the beginning in the previous system.
2021-04-28 01:37:16 +02:00
*volume = state->end_volume;
state->step_ms = 0;
return Fade_finished;
Factor fade amount calculation to separate function This makes it so to reuse this code, we don't have to copy-paste it. Additionally, I added a check for the milliseconds being 0, to avoid a division by zero. Logically and mathematically, if the fade amount is 0 milliseconds, then that means the fade should happen instantly - however, dividing by zero is undefined (both in math and in C/C++), so this check needs to be added.
2021-04-02 21:02:01 +02:00
}
Fix fade volume durations being incorrect The previous fade system used only one variable, the amount of volume to fade per frame. However, this variable was an integer, meaning any decimal portion would be truncated, and would lead to a longer fade duration than intended. The fade per volume is calculated by doing MIX_MAX_VOLUME / (fade_ms / game.get_timestep()). MIX_MAX_VOLUME is 128, and game.get_timestep() is usually 34, so a 3000 millisecond fade would be calculated as 128 / (3000 / 34). 3000 / 34 is 88.235..., but that gets truncated to 88, and then 128 / 88 becomes 1.454545..., which then gets truncated to 1. This essentially means 1 is added to or subtracted from the volume every frame, and given that the max volume is 128, this means that the fade lasts for 128 frames. Now, instead of the fade duration lasting 3 seconds, the fade now lasts for 128 frames, which is 128 * 34 / 1000 = 4.352 seconds long. This could be fixed using floats, but when you introduce floats, you now have 1.9999998 problems. For instance, I'm concerned about floating-point determinism issues. What I've done instead is switch the system to use four different variables instead: the start volume, the end volume, the total duration, and the duration completed so far (called the "step"). For every frame, the game interpolates which value should be used based on the step, the total duration, and the start and end volumes, and then adds the timestep to the step. This way, fades will be correctly timed, and we don't have potential determinism issues. Doing this also fixes inaccuracies with the game timestep changing during the fade, since the timestep is only used in the calculation once at the beginning in the previous system.
2021-04-28 01:37:16 +02:00
range = state->end_volume - state->start_volume;
new_volume = range * state->step_ms / state->duration_ms;
new_volume += state->start_volume;
*volume = new_volume;
state->step_ms += game.get_timestep();
return Fade_continue;
Factor fade amount calculation to separate function This makes it so to reuse this code, we don't have to copy-paste it. Additionally, I added a check for the milliseconds being 0, to avoid a division by zero. Logically and mathematically, if the fade amount is 0 milliseconds, then that means the fade should happen instantly - however, dividing by zero is undefined (both in math and in C/C++), so this check needs to be added.
2021-04-02 21:02:01 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void musicclass::fadeMusicVolumeIn(int ms)
{
m_doFadeInVol = true;
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
m_doFadeOutVol = false;
Ensure all fade-ins start from zero This fixes a bug where fading music in but not going through the music.play() path wouldn't start the fade volume from zero. If this happened, then the previous volume would persist, and if the previous volume was the max volume, then that essentially canceled out the fade-in and prevented it from happening at all. But now all paths to fadeMusicVolumeIn() set the volume to zero first, instead of only the caller of music.play().
2021-04-12 19:38:44 +02:00
/* Ensure it starts at 0 */
musicVolume = 0;
Fix 1-frame glitch when fading in from zero The problem here is that even though we start playing the music when the volume is set to zero, mixer's state doesn't have volume zero, so whatever it plays next will be the very first quanta of the track but at the previous volume (in this case, the maximum volume). To fix this, just update mixer when we update the volume here - it's okay to not account for user volume because it ends up being zero anyway. Fixes #710.
2021-04-12 19:41:44 +02:00
/* Fix 1-frame glitch */
Mix_VolumeMusic(0);
Music: Reset step_ms on every fade call. Without this you end up with two problems: - Fades will start past their fade time, causing it to just not fade at all - Fades will start in the middle of their fade time, causing dramatic changes in volume that are unintentional The fade system already preserves the volume that music is playing during a previous fade, so we can always reset the timer and get a good result. Part of #764
2021-06-14 21:09:23 +02:00
fade.step_ms = 0;
Fix fade volume durations being incorrect The previous fade system used only one variable, the amount of volume to fade per frame. However, this variable was an integer, meaning any decimal portion would be truncated, and would lead to a longer fade duration than intended. The fade per volume is calculated by doing MIX_MAX_VOLUME / (fade_ms / game.get_timestep()). MIX_MAX_VOLUME is 128, and game.get_timestep() is usually 34, so a 3000 millisecond fade would be calculated as 128 / (3000 / 34). 3000 / 34 is 88.235..., but that gets truncated to 88, and then 128 / 88 becomes 1.454545..., which then gets truncated to 1. This essentially means 1 is added to or subtracted from the volume every frame, and given that the max volume is 128, this means that the fade lasts for 128 frames. Now, instead of the fade duration lasting 3 seconds, the fade now lasts for 128 frames, which is 128 * 34 / 1000 = 4.352 seconds long. This could be fixed using floats, but when you introduce floats, you now have 1.9999998 problems. For instance, I'm concerned about floating-point determinism issues. What I've done instead is switch the system to use four different variables instead: the start volume, the end volume, the total duration, and the duration completed so far (called the "step"). For every frame, the game interpolates which value should be used based on the step, the total duration, and the start and end volumes, and then adds the timestep to the step. This way, fades will be correctly timed, and we don't have potential determinism issues. Doing this also fixes inaccuracies with the game timestep changing during the fade, since the timestep is only used in the calculation once at the beginning in the previous system.
2021-04-28 01:37:16 +02:00
fade.duration_ms = ms;
fade.start_volume = 0;
fade.end_volume = MIX_MAX_VOLUME;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
void musicclass::fadeMusicVolumeOut(const int fadeout_ms)
{
m_doFadeInVol = false;
m_doFadeOutVol = true;
Fix fade volume durations being incorrect The previous fade system used only one variable, the amount of volume to fade per frame. However, this variable was an integer, meaning any decimal portion would be truncated, and would lead to a longer fade duration than intended. The fade per volume is calculated by doing MIX_MAX_VOLUME / (fade_ms / game.get_timestep()). MIX_MAX_VOLUME is 128, and game.get_timestep() is usually 34, so a 3000 millisecond fade would be calculated as 128 / (3000 / 34). 3000 / 34 is 88.235..., but that gets truncated to 88, and then 128 / 88 becomes 1.454545..., which then gets truncated to 1. This essentially means 1 is added to or subtracted from the volume every frame, and given that the max volume is 128, this means that the fade lasts for 128 frames. Now, instead of the fade duration lasting 3 seconds, the fade now lasts for 128 frames, which is 128 * 34 / 1000 = 4.352 seconds long. This could be fixed using floats, but when you introduce floats, you now have 1.9999998 problems. For instance, I'm concerned about floating-point determinism issues. What I've done instead is switch the system to use four different variables instead: the start volume, the end volume, the total duration, and the duration completed so far (called the "step"). For every frame, the game interpolates which value should be used based on the step, the total duration, and the start and end volumes, and then adds the timestep to the step. This way, fades will be correctly timed, and we don't have potential determinism issues. Doing this also fixes inaccuracies with the game timestep changing during the fade, since the timestep is only used in the calculation once at the beginning in the previous system.
2021-04-28 01:37:16 +02:00
Music: Reset step_ms on every fade call. Without this you end up with two problems: - Fades will start past their fade time, causing it to just not fade at all - Fades will start in the middle of their fade time, causing dramatic changes in volume that are unintentional The fade system already preserves the volume that music is playing during a previous fade, so we can always reset the timer and get a good result. Part of #764
2021-06-14 21:09:23 +02:00
fade.step_ms = 0;
Make fade out duration proportional to volume This is the same behavior as SDL_mixer. Else, a fadeout would last the same amount of time no matter the volume, which is a regression.
2021-08-23 01:57:13 +02:00
/* Duration is proportional to current volume. */
fade.duration_ms = fadeout_ms * musicVolume / MIX_MAX_VOLUME;
Fix fade volume durations being incorrect The previous fade system used only one variable, the amount of volume to fade per frame. However, this variable was an integer, meaning any decimal portion would be truncated, and would lead to a longer fade duration than intended. The fade per volume is calculated by doing MIX_MAX_VOLUME / (fade_ms / game.get_timestep()). MIX_MAX_VOLUME is 128, and game.get_timestep() is usually 34, so a 3000 millisecond fade would be calculated as 128 / (3000 / 34). 3000 / 34 is 88.235..., but that gets truncated to 88, and then 128 / 88 becomes 1.454545..., which then gets truncated to 1. This essentially means 1 is added to or subtracted from the volume every frame, and given that the max volume is 128, this means that the fade lasts for 128 frames. Now, instead of the fade duration lasting 3 seconds, the fade now lasts for 128 frames, which is 128 * 34 / 1000 = 4.352 seconds long. This could be fixed using floats, but when you introduce floats, you now have 1.9999998 problems. For instance, I'm concerned about floating-point determinism issues. What I've done instead is switch the system to use four different variables instead: the start volume, the end volume, the total duration, and the duration completed so far (called the "step"). For every frame, the game interpolates which value should be used based on the step, the total duration, and the start and end volumes, and then adds the timestep to the step. This way, fades will be correctly timed, and we don't have potential determinism issues. Doing this also fixes inaccuracies with the game timestep changing during the fade, since the timestep is only used in the calculation once at the beginning in the previous system.
2021-04-28 01:37:16 +02:00
fade.start_volume = musicVolume;
fade.end_volume = 0;
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
}
Clean up don't-quick-fade signaling First, the variable has been inverted, because it's bad practice to have booleans with negative names. Secondly, instead of magically setting a signaling variable when calling fadeout(), fadeout() now has a parameter to set the quick_fade attribute, which is much cleaner than doing the magical assignment that could potentially look unrelated.
2020-11-06 09:51:04 +01:00
void musicclass::fadeout(const bool quick_fade_ /*= true*/)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Music: Enforce the quick fade time as soon as we know it's happening. Not every music path will trip the quick_fade bool that resets the timer to 500ms, so we need to do this as soon as it's asked of us. This fixes the fade when quitting to the main menu. Fixes #764
2021-06-14 21:11:39 +02:00
fadeMusicVolumeOut(quick_fade_ ? 500 : 2000);
Clean up don't-quick-fade signaling First, the variable has been inverted, because it's bad practice to have booleans with negative names. Secondly, instead of magically setting a signaling variable when calling fadeout(), fadeout() now has a parameter to set the quick_fade attribute, which is much cleaner than doing the magical assignment that could potentially look unrelated.
2020-11-06 09:51:04 +01:00
quick_fade = quick_fade_;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void musicclass::processmusicfadein(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix fade volume durations being incorrect The previous fade system used only one variable, the amount of volume to fade per frame. However, this variable was an integer, meaning any decimal portion would be truncated, and would lead to a longer fade duration than intended. The fade per volume is calculated by doing MIX_MAX_VOLUME / (fade_ms / game.get_timestep()). MIX_MAX_VOLUME is 128, and game.get_timestep() is usually 34, so a 3000 millisecond fade would be calculated as 128 / (3000 / 34). 3000 / 34 is 88.235..., but that gets truncated to 88, and then 128 / 88 becomes 1.454545..., which then gets truncated to 1. This essentially means 1 is added to or subtracted from the volume every frame, and given that the max volume is 128, this means that the fade lasts for 128 frames. Now, instead of the fade duration lasting 3 seconds, the fade now lasts for 128 frames, which is 128 * 34 / 1000 = 4.352 seconds long. This could be fixed using floats, but when you introduce floats, you now have 1.9999998 problems. For instance, I'm concerned about floating-point determinism issues. What I've done instead is switch the system to use four different variables instead: the start volume, the end volume, the total duration, and the duration completed so far (called the "step"). For every frame, the game interpolates which value should be used based on the step, the total duration, and the start and end volumes, and then adds the timestep to the step. This way, fades will be correctly timed, and we don't have potential determinism issues. Doing this also fixes inaccuracies with the game timestep changing during the fade, since the timestep is only used in the calculation once at the beginning in the previous system.
2021-04-28 01:37:16 +02:00
enum FadeCode fade_code = processmusicfade(&fade, &musicVolume);
if (fade_code == Fade_finished)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
m_doFadeInVol = false;
}
}
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
void musicclass::processmusicfadeout(void)
{
Fix fade volume durations being incorrect The previous fade system used only one variable, the amount of volume to fade per frame. However, this variable was an integer, meaning any decimal portion would be truncated, and would lead to a longer fade duration than intended. The fade per volume is calculated by doing MIX_MAX_VOLUME / (fade_ms / game.get_timestep()). MIX_MAX_VOLUME is 128, and game.get_timestep() is usually 34, so a 3000 millisecond fade would be calculated as 128 / (3000 / 34). 3000 / 34 is 88.235..., but that gets truncated to 88, and then 128 / 88 becomes 1.454545..., which then gets truncated to 1. This essentially means 1 is added to or subtracted from the volume every frame, and given that the max volume is 128, this means that the fade lasts for 128 frames. Now, instead of the fade duration lasting 3 seconds, the fade now lasts for 128 frames, which is 128 * 34 / 1000 = 4.352 seconds long. This could be fixed using floats, but when you introduce floats, you now have 1.9999998 problems. For instance, I'm concerned about floating-point determinism issues. What I've done instead is switch the system to use four different variables instead: the start volume, the end volume, the total duration, and the duration completed so far (called the "step"). For every frame, the game interpolates which value should be used based on the step, the total duration, and the start and end volumes, and then adds the timestep to the step. This way, fades will be correctly timed, and we don't have potential determinism issues. Doing this also fixes inaccuracies with the game timestep changing during the fade, since the timestep is only used in the calculation once at the beginning in the previous system.
2021-04-28 01:37:16 +02:00
enum FadeCode fade_code = processmusicfade(&fade, &musicVolume);
if (fade_code == Fade_finished)
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
{
musicVolume = 0;
m_doFadeOutVol = false;
Fix playing same track after it has faded out If a track was restarted after it faded out, then it wouldn't play. This is because currentsong wasn't set to -1 after fading out, and that is because the fade out calls pause() instead of haltdasmusik() when it finishes. Unlike f196fcd896defc0b24690851c701b8273ba8074b, this fixes the time trial music while keeping it to the same behavior as 2.2, and fixes every single possible case that this music bug could have happened.
2021-04-14 18:34:01 +02:00
haltdasmusik();
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
}
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void musicclass::processmusic(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if(!safeToProcessMusic)
{
return;
}
if(m_doFadeInVol)
{
processmusicfadein();
}
Re-fix resumemusic/musicfadein once again So it looks like facb079b3597b380f876537523cd351a0e637b62 (PR #316) had a few issues. The SDL performance counter doesn't really work that well. Testing reveals that unfocusing and focusing the game again results in the resumemusic() script command resuming the track at the wrong time. Even when not unfocusing the game at all, stopping a track and resuming it resumes it at the wrong time. (Only disabling the unfocus pause fixes this.) Furthermore, there's also the fact that the SDL performance counter keeps incrementing when the game is paused under GDB. So... yeah. Instead of dealing with the SDL performance counter, I'm just going to pause and resume the music directly (so the stopmusic() script command just pauses the music instead). As a result, we no longer can keep constantly calling Mix_PauseMusic() or Mix_ResumeMusic() when focused or unfocused, so I've moved those calls to happen directly when the relevant SDL events are received (the constant calls were originally in VCE, and whoever added them (I'm pretty sure it was Leo) was not the sharpest tool in the shed...). And we are going to switch over to using our own fade system instead of the SDL mixer fade system. In fact, we were already using our own fade system for fadeins after collecting a trinket or a custom level crewmate, but we were still using the mixer system for the rest. This is an inconsistency that I am glad to correct, so we're also doing our own fadeouts now. There is, however, an issue with the fade system where the length it goes for is inaccurate, because it's based on a volume-per-frame second calculation that gets truncated. But that's an issue to fix later - at least what I'm doing right now makes resumemusic() and musicfadein() work better than before.
2021-04-02 21:56:25 +02:00
if (m_doFadeOutVol)
{
processmusicfadeout();
}
Process queued music after processing fades While fixing all the other music bugs, I discovered that starting playtesting in the editor wouldn't play the level music. The problem is that the editor playtesting start code calls music.fadeout() before calling music.play(). This queues up the track from the music.play() call. After that, what should happen is that processmusic() processes the fade, the fade is then finished, and then after that it sees that the music is halted so it can play the queued track. Instead what happens is that the function first attempts to play the music before the fade is processed and finished, so play() will re-queue the music again, but the queue gets cleared right after that (this is a subtle bit of behavior - it means if the game fails to play a queued track due to it fading, it's not going to re-queue it again and end up in some sort of infinite loop). This is a frame ordering issue - the function is tripping over itself when it shouldn't be. To fix it, just put the queue processing code after the fade processing code.
2021-04-12 21:18:11 +02:00
/* This needs to come after processing fades */
if (nicefade && Mix_PausedMusic() == 1)
{
play(nicechange);
nicechange = -1;
nicefade = false;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
void musicclass::niceplay(int t)
{
Fix up style in musicclass::play() - Multiline comment instead of single-line. - Spacing fixes. - Long line broken up into smaller ones.
2021-08-23 00:27:39 +02:00
/* important: do nothing if the correct song is playing! */
if ((!mmmmmm && currentsong != t)
|| (mmmmmm && usingmmmmmm && currentsong != t)
|| (mmmmmm && !usingmmmmmm && currentsong != t + num_mmmmmm_tracks))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix up style in musicclass::play() - Multiline comment instead of single-line. - Spacing fixes. - Long line broken up into smaller ones.
2021-08-23 00:27:39 +02:00
if (currentsong != -1)
Don't quick fade when using niceplay() Earlier in 53950e14de65a54d9369c5183a16337782d3dc4e, I made playing a song while a song was already fading quickly fade out the current song, but then added an exception for if the fade came from the musicfadeout() command. This commit adds another exception for if the fade came from niceplay(), since otherwise the music transitions between areas in the game would go too quick.
2020-01-23 01:26:29 +01:00
{
Clean up don't-quick-fade signaling First, the variable has been inverted, because it's bad practice to have booleans with negative names. Secondly, instead of magically setting a signaling variable when calling fadeout(), fadeout() now has a parameter to set the quick_fade attribute, which is much cleaner than doing the magical assignment that could potentially look unrelated.
2020-11-06 09:51:04 +01:00
fadeout(false);
Don't quick fade when using niceplay() Earlier in 53950e14de65a54d9369c5183a16337782d3dc4e, I made playing a song while a song was already fading quickly fade out the current song, but then added an exception for if the fade came from the musicfadeout() command. This commit adds another exception for if the fade came from niceplay(), since otherwise the music transitions between areas in the game would go too quick.
2020-01-23 01:26:29 +01:00
}
Change nicefade to bool instead of int If it's treated like a bool, why shouldn't it be one?
2020-11-06 09:20:58 +01:00
nicefade = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Fix regression with niceplay() moving back and forth between zones 2.3 has a regression where if you move back and forth between a zone, you can get the wrong music playing in a zone. An example is the Overworld and Lab. Just walk in to the Lab and immediately walk back out, and you'll get Potential for Anything playing in the Overworld. This regression was caused by facb079b3597b380f876537523cd351a0e637b62. That commit removed assigning -1 to currentsong when a fadeout was called. Basically, the previous behavior was: currentsong is 4, we enter Lab and nicechange gets queued to 3 but currentsong gets set to -1, then going back nicechange gets queued to 4 again. However, if we don't assign -1, then going back will keep nicechange at 3. Why? Because niceplay() checks for currentsong before assigning nicechange. If currentsong is still the same then it doesn't assign nicechange. To fix this, just always unconditionally assign nicechange.
2021-08-23 00:54:45 +02:00
nicechange = t;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Replace main game music with music area map The main game used a set of copy-pasted code to set the music of each area. There WAS some redundancy built-in, but only three rooms in each direction from the entrance of a zone. Given this, it's completely possible for players to mismatch the music of the area and level. In fact, it's easy to do it even on accident, especially since 2.3 now lets you quicksave and quit during cutscenes. Just play a cutscene that has Pause music, then quicksave, quit, and reload. Also some other accidental ways that I've forgotten about. To fix this, I've done what mapclass has and made an areamap. Except for music. This map is the map of the track number of every single room, except for three special cases: -1 for do nothing and don't change music (usually because multiple different tracks can be played in this room), -2 for Tower music (needs to be track 2 or 9 depending on Flip Mode), and -3 for the start of Space Station 2 (track 1 in time trials, track 4 otherwise). I've thoroughly tested this areamap by playing through the game and entering every single room. Additionally I've also thoroughly tested all special cases (entering the Ship through the teleporter or main entrance, using the Ship's jukebox, the Tower in Flip Mode and regular mode, and the start of Space Station 2 in time trial and in regular mode). Closes #449.
2021-05-12 04:59:02 +02:00
static const int areamap[] = {
4, 3, 3, 3, 3, 3, 3, 3, 4,-2, 4, 4, 4,12,12,12,12,12,12,12,
4, 3, 3, 3, 3, 3, 3, 4, 4,-2, 4, 4, 4, 4,12,12,12,12,12,12,
4, 4, 4, 4, 3, 4, 4, 4, 4,-2, 4, 4, 4, 4,12,12,12,12,12,12,
4, 4, 4, 4, 3, 4, 4, 4, 4,-2, 4, 4, 1, 1, 1, 1,12,12,12,12,
4, 4, 3, 3, 3, 4, 4, 4, 4,-2,-2,-2, 1, 1, 1, 1, 4, 4, 4, 4,
4, 4, 4, 4, 4, 4, 4, 4, 4,-2, 1, 1, 1, 1, 1, 1,11,11,-1, 4,
4, 4, 4, 4, 4, 4, 4, 4, 4,-2, 1, 1, 1, 1, 1, 1, 1,11,11,11,
4, 4, 4, 4, 4, 4, 4, 4, 4,-2, 1, 1, 1, 1, 1, 1, 1, 1, 1,11,
4, 4, 4, 4, 4, 4, 4, 4, 4,-2, 4, 4, 4, 1, 1, 1, 1, 1, 1, 3,
4, 4, 4, 4, 4, 4, 4, 4,-2,-2, 4, 4, 4, 1, 1, 1, 1, 1, 1, 4,
4, 4,-1,-1,-1, 4, 4, 4, 4,-2, 4, 4, 4, 1, 1, 1, 1, 1, 1, 4,
4, 4,-1,-1,-1, 4, 4, 4, 4,-2, 4, 1, 1, 1, 1, 1, 1, 1, 1, 4,
4, 4, 4, 4, 4, 4, 4, 4, 4,-2, 4, 1, 1, 1, 1, 1, 1, 4, 1, 4,
4, 4, 4, 4, 4, 4, 4, 4, 4,-2, 4, 1, 1, 1, 1, 1, 1, 4, 1, 4,
4, 4, 4, 4, 4, 4, 4, 4, 4,-2, 4,-1,-3, 4, 4, 4, 4, 4, 1, 4,
4, 4, 4, 4, 4, 3, 3, 3, 4,-2, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
4, 4, 3, 3, 3, 3, 3, 3, 4,-2, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
4, 3, 3, 3, 3, 3, 3, 3, 4,-2, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
3, 3, 3, 3, 3, 4, 4, 3, 4,-2, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
3, 3, 3, 3, 3, 4, 4, 3, 4,-2, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4
};
SDL_COMPILE_TIME_ASSERT(areamap, SDL_arraysize(areamap) == 20 * 20);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void musicclass::changemusicarea(int x, int y)
{
Replace main game music with music area map The main game used a set of copy-pasted code to set the music of each area. There WAS some redundancy built-in, but only three rooms in each direction from the entrance of a zone. Given this, it's completely possible for players to mismatch the music of the area and level. In fact, it's easy to do it even on accident, especially since 2.3 now lets you quicksave and quit during cutscenes. Just play a cutscene that has Pause music, then quicksave, quit, and reload. Also some other accidental ways that I've forgotten about. To fix this, I've done what mapclass has and made an areamap. Except for music. This map is the map of the track number of every single room, except for three special cases: -1 for do nothing and don't change music (usually because multiple different tracks can be played in this room), -2 for Tower music (needs to be track 2 or 9 depending on Flip Mode), and -3 for the start of Space Station 2 (track 1 in time trials, track 4 otherwise). I've thoroughly tested this areamap by playing through the game and entering every single room. Additionally I've also thoroughly tested all special cases (entering the Ship through the teleporter or main entrance, using the Ship's jukebox, the Tower in Flip Mode and regular mode, and the start of Space Station 2 in time trial and in regular mode). Closes #449.
2021-05-12 04:59:02 +02:00
int room;
int track;
if (script.running)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace main game music with music area map The main game used a set of copy-pasted code to set the music of each area. There WAS some redundancy built-in, but only three rooms in each direction from the entrance of a zone. Given this, it's completely possible for players to mismatch the music of the area and level. In fact, it's easy to do it even on accident, especially since 2.3 now lets you quicksave and quit during cutscenes. Just play a cutscene that has Pause music, then quicksave, quit, and reload. Also some other accidental ways that I've forgotten about. To fix this, I've done what mapclass has and made an areamap. Except for music. This map is the map of the track number of every single room, except for three special cases: -1 for do nothing and don't change music (usually because multiple different tracks can be played in this room), -2 for Tower music (needs to be track 2 or 9 depending on Flip Mode), and -3 for the start of Space Station 2 (track 1 in time trials, track 4 otherwise). I've thoroughly tested this areamap by playing through the game and entering every single room. Additionally I've also thoroughly tested all special cases (entering the Ship through the teleporter or main entrance, using the Ship's jukebox, the Tower in Flip Mode and regular mode, and the start of Space Station 2 in time trial and in regular mode). Closes #449.
2021-05-12 04:59:02 +02:00
return;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Replace main game music with music area map The main game used a set of copy-pasted code to set the music of each area. There WAS some redundancy built-in, but only three rooms in each direction from the entrance of a zone. Given this, it's completely possible for players to mismatch the music of the area and level. In fact, it's easy to do it even on accident, especially since 2.3 now lets you quicksave and quit during cutscenes. Just play a cutscene that has Pause music, then quicksave, quit, and reload. Also some other accidental ways that I've forgotten about. To fix this, I've done what mapclass has and made an areamap. Except for music. This map is the map of the track number of every single room, except for three special cases: -1 for do nothing and don't change music (usually because multiple different tracks can be played in this room), -2 for Tower music (needs to be track 2 or 9 depending on Flip Mode), and -3 for the start of Space Station 2 (track 1 in time trials, track 4 otherwise). I've thoroughly tested this areamap by playing through the game and entering every single room. Additionally I've also thoroughly tested all special cases (entering the Ship through the teleporter or main entrance, using the Ship's jukebox, the Tower in Flip Mode and regular mode, and the start of Space Station 2 in time trial and in regular mode). Closes #449.
2021-05-12 04:59:02 +02:00
room = musicroom(x, y);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Replace main game music with music area map The main game used a set of copy-pasted code to set the music of each area. There WAS some redundancy built-in, but only three rooms in each direction from the entrance of a zone. Given this, it's completely possible for players to mismatch the music of the area and level. In fact, it's easy to do it even on accident, especially since 2.3 now lets you quicksave and quit during cutscenes. Just play a cutscene that has Pause music, then quicksave, quit, and reload. Also some other accidental ways that I've forgotten about. To fix this, I've done what mapclass has and made an areamap. Except for music. This map is the map of the track number of every single room, except for three special cases: -1 for do nothing and don't change music (usually because multiple different tracks can be played in this room), -2 for Tower music (needs to be track 2 or 9 depending on Flip Mode), and -3 for the start of Space Station 2 (track 1 in time trials, track 4 otherwise). I've thoroughly tested this areamap by playing through the game and entering every single room. Additionally I've also thoroughly tested all special cases (entering the Ship through the teleporter or main entrance, using the Ship's jukebox, the Tower in Flip Mode and regular mode, and the start of Space Station 2 in time trial and in regular mode). Closes #449.
2021-05-12 04:59:02 +02:00
if (!INBOUNDS_ARR(room, areamap))
{
SDL_assert(0 && "Music map index out-of-bounds!");
return;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Replace main game music with music area map The main game used a set of copy-pasted code to set the music of each area. There WAS some redundancy built-in, but only three rooms in each direction from the entrance of a zone. Given this, it's completely possible for players to mismatch the music of the area and level. In fact, it's easy to do it even on accident, especially since 2.3 now lets you quicksave and quit during cutscenes. Just play a cutscene that has Pause music, then quicksave, quit, and reload. Also some other accidental ways that I've forgotten about. To fix this, I've done what mapclass has and made an areamap. Except for music. This map is the map of the track number of every single room, except for three special cases: -1 for do nothing and don't change music (usually because multiple different tracks can be played in this room), -2 for Tower music (needs to be track 2 or 9 depending on Flip Mode), and -3 for the start of Space Station 2 (track 1 in time trials, track 4 otherwise). I've thoroughly tested this areamap by playing through the game and entering every single room. Additionally I've also thoroughly tested all special cases (entering the Ship through the teleporter or main entrance, using the Ship's jukebox, the Tower in Flip Mode and regular mode, and the start of Space Station 2 in time trial and in regular mode). Closes #449.
2021-05-12 04:59:02 +02:00
track = areamap[room];
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Replace main game music with music area map The main game used a set of copy-pasted code to set the music of each area. There WAS some redundancy built-in, but only three rooms in each direction from the entrance of a zone. Given this, it's completely possible for players to mismatch the music of the area and level. In fact, it's easy to do it even on accident, especially since 2.3 now lets you quicksave and quit during cutscenes. Just play a cutscene that has Pause music, then quicksave, quit, and reload. Also some other accidental ways that I've forgotten about. To fix this, I've done what mapclass has and made an areamap. Except for music. This map is the map of the track number of every single room, except for three special cases: -1 for do nothing and don't change music (usually because multiple different tracks can be played in this room), -2 for Tower music (needs to be track 2 or 9 depending on Flip Mode), and -3 for the start of Space Station 2 (track 1 in time trials, track 4 otherwise). I've thoroughly tested this areamap by playing through the game and entering every single room. Additionally I've also thoroughly tested all special cases (entering the Ship through the teleporter or main entrance, using the Ship's jukebox, the Tower in Flip Mode and regular mode, and the start of Space Station 2 in time trial and in regular mode). Closes #449.
2021-05-12 04:59:02 +02:00
switch (track)
{
case -1:
/* Don't change music. */
return;
case -2:
/* Special case: Tower music, changes with Flip Mode. */
if (graphics.setflipmode)
{
track = 9; /* ecroF evitisoP */
}
else
{
track = 2; /* Positive Force */
}
break;
case -3:
/* Special case: start of Space Station 2. */
if (game.intimetrial)
{
track = 1; /* Pushing Onwards */
}
else
{
track = 4; /* Passion for Exploring */
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
}
Replace main game music with music area map The main game used a set of copy-pasted code to set the music of each area. There WAS some redundancy built-in, but only three rooms in each direction from the entrance of a zone. Given this, it's completely possible for players to mismatch the music of the area and level. In fact, it's easy to do it even on accident, especially since 2.3 now lets you quicksave and quit during cutscenes. Just play a cutscene that has Pause music, then quicksave, quit, and reload. Also some other accidental ways that I've forgotten about. To fix this, I've done what mapclass has and made an areamap. Except for music. This map is the map of the track number of every single room, except for three special cases: -1 for do nothing and don't change music (usually because multiple different tracks can be played in this room), -2 for Tower music (needs to be track 2 or 9 depending on Flip Mode), and -3 for the start of Space Station 2 (track 1 in time trials, track 4 otherwise). I've thoroughly tested this areamap by playing through the game and entering every single room. Additionally I've also thoroughly tested all special cases (entering the Ship through the teleporter or main entrance, using the Ship's jukebox, the Tower in Flip Mode and regular mode, and the start of Space Station 2 in time trial and in regular mode). Closes #449.
2021-05-12 04:59:02 +02:00
niceplay(track);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
void musicclass::playef(int t)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't manually write out INBOUNDS_VEC() checks This is because if they are manually written out, they are more likely to contain mistakes. In fact, after further review, there are several functions with incorrect manually-written bounds checks: * entityclass::entitycollide() * entityclass::removeentity() * entityclass::removeblock() * entityclass::copylinecross() * entityclass::revertlinecross() All of those functions forgot to do 'greater than or equal to' instead of 'greater than' when comparing against the size of the vector. So they were erroneous. But they are now fixed.
2020-09-10 06:58:59 +02:00
if (!INBOUNDS_VEC(t, soundTracks))
Add bounds checks to script commands that didn't have them Continuing from #280, another potential source of out-of-bounds indexing (and thus, Undefined Behavior badness) comes from script commands. A majority of them don't do any input validation at all, which means the potential for out-of-bounds indexing and segfaulting in custom levels. So it's always good to add bounds checks to them. Interesting note, the only existing command that has bounds checks is the flag() command. That means you can't turn out-of-bounds flags on or off. But there's no bounds checks for ifflag(), or customifflag(), which means you CAN index out-of-bounds with those commands! That's a bit bad to do, so. Also, I decided to add the bounds checks for playef() at the musicclass::playef() level, instead of just the level of the playef() command. I don't know of any other cases outside of the command where musicclass::playef() will index out of bounds, but musicclass is the one containing the indexed vector anyway, I wanted to cover more cases, and it's better to be safe than sorry.
2020-06-13 06:55:41 +02:00
{
return;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int channel;
channel = Mix_PlayChannel(-1, soundTracks[t].sound, 0);
if(channel == -1)
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Unable to play WAV file: %s", Mix_GetError());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Add pause(), pauseef(), and resumeef() to musicclass musicclass already had a resume() function for music. These are just wrappers around the appropriate SDL_mixer functions, to avoid direct function calls to the mixer API. So if we ever need to do something with all callers of pausing and resuming in the future, or we switch to a different audio backend, the work is already done for us. Also it just looks cleaner to be calling our musicclass function instead of doing a direct API call to the mixer.
2021-04-02 21:07:19 +02:00
void musicclass::pauseef(void)
{
Mix_Pause(-1);
}
void musicclass::resumeef(void)
{
Mix_Resume(-1);
}
Reference in a new issue Copy permalink