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.h

80 lines
1.5 KiB
C
Raw Normal View History

Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#ifndef MUSIC_H
#define MUSIC_H
#include <vector>
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 "BinaryBlob.h"
#include "SoundSystem.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#define musicroom(rx, ry) ((rx) + ((ry) * 20))
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
/* The amount of "space" for the scale of the user-set volume. */
#define USER_VOLUME_MAX 256
Implement music and sound volume sliders This adds music and volume sliders to the audio options. To use the sliders, you navigate to the given option, then press ACTION, and your selection will be transferred to the slider. Pressing left or right will move the slider accordingly. Then you can press ACTION to confirm the volume is what you want and deselect it, or you can press Esc to cancel the volume change, and it will revert to the previous volume; both actions will write your settings to disk. Most of this commit is just adding infrastructure to support having sliders in menus (without copy-pasting code), which is a totally completely new user interface that has never been used before in this game. If we're going to be adding something new, I want to make sure that it at least is done the RIGHT way. Closes #706.
2021-04-12 02:43:17 +02:00
/* It is advised that USER_VOLUME_MAX be divisible by this. */
#define USER_VOLUME_STEP 32
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
class musicclass
{
public:
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(void);
void init(void);
void destroy(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
void play(int t);
void resume();
void resumefade(const int fadein_ms);
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 pause(void);
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 haltdasmusik(void);
void silencedasmusik(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void fadeMusicVolumeIn(int ms);
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 fadeMusicVolumeOut(const int fadeout_ms);
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 fadeout(const bool quick_fade_ = true);
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 fadein(void);
void processmusicfadein(void);
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 processmusicfadeout(void);
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 processmusic(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void niceplay(int t);
void changemusicarea(int x, int y);
Remove unused/useless vars music.custompd/musicfade(in)/volume I have no idea why these are here, but it'll simplify readability and reduce the chance of confusion if I remove them.
2020-06-27 10:40:58 +02:00
int currentsong;
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 playef(int t);
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 pauseef(void);
void resumeef(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::vector<SoundTrack> soundTracks;
std::vector<MusicTrack> musicTracks;
SoundSystem soundSystem;
bool safeToProcessMusic;
Merge fadeoutqueuesong into nicechange fadeoutqueuesong basically does the same thing as nicechange - they both queue a song to be played when the current track is done fading out. Except, for some reason, I decided to add fadeoutqueuesong instead of using the existing nicechange/nicefade system. This has consequences where fadeoutqueuesong would step on the toes of nicechange. In the case of #390, nicechange would say "let's play Potential for Anything" when entering the Super Gravitron, but fadeoutqueuesong had previously said "let's play Pipe Dream" because of the player having just exited the Super Gravitron. fadeoutqueuesong took priority because it came first in musicclass::processfade(), and when it called play(), the Mix_PlayingMusic() in the nicechange check afterwards would say music would already be playing at that point, so the nicechange wouldn't take effect. In the end, the solution is to just merge the new system into the already-existing system. Fixes #390.
2020-11-06 09:36:25 +01:00
int nicechange; // -1 if no song queued
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
bool nicefade;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
bool m_doFadeInVol;
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
bool m_doFadeOutVol;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int musicVolume;
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
/* 0..USER_VOLUME_MAX */
int user_music_volume;
int user_sound_volume;
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
bool quick_fade;
Stop the game from freezing if we play a song during a fadeout (#61)
2020-01-13 04:33:58 +01:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
// MMMMMM mod settings
bool mmmmmm;
bool usingmmmmmm;
Don't leak binaryBlob
2020-06-07 22:11:35 +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
binaryBlob pppppp_blob;
binaryBlob mmmmmm_blob;
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
int num_pppppp_tracks;
int num_mmmmmm_tracks;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
};
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
#ifndef MUSIC_DEFINITION
Allow using help/graphics/music/game/key/map/obj everywhere This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and `obj` essentially static global objects that can be used everywhere. This is useful in case we ever need to add a new function in the future, so we don't have to bother with passing a new argument in which means we have to pass a new argument in to the function that calls that function which means having to pass a new argument into the function that calls THAT function, etc. which is a real headache when working on fan mods of the source code. Note that this changes NONE of the existing function signatures, it merely just makes those variables accessible everywhere in the same way `script` and `ed` are. Also note that some classes had to be initialized after the filesystem was initialized, but C++ would keep initializing them before the filesystem got initialized, because I *had* to put them at the top of `main.cpp`, or else they wouldn't be global variables. The only way to work around this was to use entityclass's initialization style (which I'm pretty sure entityclass of all things doesn't need to be initialized this way), where you actually initialize the class in an `init()` function, and so then you do `graphics.init()` after the filesystem initialization, AFTER doing `Graphics graphics` up at the top. I've had to do this for `graphics` (but only because its child GraphicsResources `grphx` needs to be initialized this way), `music`, and `game`. I don't think this will affect anything. Other than that, `help`, `key`, and `map` are still using the C++-intended method of having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
extern musicclass music;
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
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#endif /* MUSIC_H */
Reference in a new issue Copy permalink