mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-11-05 02:39:41 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/Input.cpp

2576 lines
78 KiB
C++
Raw Normal View History

Use angle brackets for including tinyxml2.h Since TinyXML2 is a third-party dependency, we should use angle brackets and treat it like one.
2020-07-19 21:03:16 +02:00
#include <tinyxml2.h>
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 "Credits.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 "editor.h"
#include "Entity.h"
#include "Enums.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
#include "FileSystemUtils.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 "Game.h"
#include "Graphics.h"
#include "KeyPoll.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
#include "MakeAndPlay.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 "Map.h"
#include "Music.h"
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
#include "RenderFixed.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
#include "Script.h"
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
#include "UtilityClass.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
Clean up unnecessary exports and add static keywords This patch cleans up unnecessary exports from header files (there were only a few), as well as adds the static keyword to all symbols that aren't exported and are specific to a file. This helps the linker out in not doing any unnecessary work, speeding it up and avoiding silent symbol conflicts (otherwise two symbols with the same name (and type/signature in C++) would quietly resolve as okay by the linker).
2021-01-10 18:14:37 +01:00
static void updatebuttonmappings(int bind)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
for (
SDL_GameControllerButton i = SDL_CONTROLLER_BUTTON_A;
i < SDL_CONTROLLER_BUTTON_DPAD_UP;
i = (SDL_GameControllerButton) (i + 1)
) {
if (key.isDown(i))
{
bool dupe = false;
if (bind == 1)
{
for (size_t j = 0; j < game.controllerButton_flip.size(); j += 1)
{
if (i == game.controllerButton_flip[j])
{
dupe = true;
}
}
if (!dupe)
{
game.controllerButton_flip.push_back(i);
music.playef(11);
}
for (size_t j = 0; j < game.controllerButton_map.size(); j += 1)
{
if (i == game.controllerButton_map[j])
{
game.controllerButton_map.erase(game.controllerButton_map.begin() + j);
}
}
for (size_t j = 0; j < game.controllerButton_esc.size(); j += 1)
{
if (i == game.controllerButton_esc[j])
{
game.controllerButton_esc.erase(game.controllerButton_esc.begin() + j);
}
}
Added ability to bind restart to a controller.
2020-08-09 00:41:59 +02:00
for (size_t j = 0; j < game.controllerButton_restart.size(); j += 1)
{
if (i == game.controllerButton_restart[j])
{
game.controllerButton_restart.erase(game.controllerButton_restart.begin() + j);
}
}
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
}
if (bind == 2)
{
for (size_t j = 0; j < game.controllerButton_map.size(); j += 1)
{
if (i == game.controllerButton_map[j])
{
dupe = true;
}
}
if (!dupe)
{
game.controllerButton_map.push_back(i);
music.playef(11);
}
for (size_t j = 0; j < game.controllerButton_flip.size(); j += 1)
{
if (i == game.controllerButton_flip[j])
{
game.controllerButton_flip.erase(game.controllerButton_flip.begin() + j);
}
}
for (size_t j = 0; j < game.controllerButton_esc.size(); j += 1)
{
if (i == game.controllerButton_esc[j])
{
game.controllerButton_esc.erase(game.controllerButton_esc.begin() + j);
}
}
Added ability to bind restart to a controller.
2020-08-09 00:41:59 +02:00
for (size_t j = 0; j < game.controllerButton_restart.size(); j += 1)
{
if (i == game.controllerButton_restart[j])
{
game.controllerButton_restart.erase(game.controllerButton_restart.begin() + j);
}
}
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
}
if (bind == 3)
{
for (size_t j = 0; j < game.controllerButton_esc.size(); j += 1)
{
if (i == game.controllerButton_esc[j])
{
dupe = true;
}
}
if (!dupe)
{
game.controllerButton_esc.push_back(i);
music.playef(11);
}
for (size_t j = 0; j < game.controllerButton_flip.size(); j += 1)
{
if (i == game.controllerButton_flip[j])
{
game.controllerButton_flip.erase(game.controllerButton_flip.begin() + j);
}
}
for (size_t j = 0; j < game.controllerButton_map.size(); j += 1)
{
if (i == game.controllerButton_map[j])
{
game.controllerButton_map.erase(game.controllerButton_map.begin() + j);
}
}
Added ability to bind restart to a controller.
2020-08-09 00:41:59 +02:00
for (size_t j = 0; j < game.controllerButton_restart.size(); j += 1)
{
if (i == game.controllerButton_restart[j])
{
game.controllerButton_restart.erase(game.controllerButton_restart.begin() + j);
}
}
}
if (bind == 4)
{
for (size_t j = 0; j < game.controllerButton_restart.size(); j += 1)
{
if (i == game.controllerButton_restart[j])
{
dupe = true;
}
}
if (!dupe)
{
game.controllerButton_restart.push_back(i);
music.playef(11);
}
for (size_t j = 0; j < game.controllerButton_flip.size(); j += 1)
{
if (i == game.controllerButton_flip[j])
{
game.controllerButton_flip.erase(game.controllerButton_flip.begin() + j);
}
}
for (size_t j = 0; j < game.controllerButton_map.size(); j += 1)
{
if (i == game.controllerButton_map[j])
{
game.controllerButton_map.erase(game.controllerButton_map.begin() + j);
}
}
for (size_t j = 0; j < game.controllerButton_esc.size(); j += 1)
{
if (i == game.controllerButton_esc[j])
{
game.controllerButton_esc.erase(game.controllerButton_esc.begin() + j);
}
}
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
}
}
}
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
static void menuactionpress(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
switch (game.currentmenuname)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::mainmenu:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
#if defined(MAKEANDPLAY)
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#define MPOFFSET -1
#else
#define MPOFFSET 0
#endif
#if defined(NO_CUSTOM_LEVELS)
#define NOCUSTOMSOFFSET -1
#else
#define NOCUSTOMSOFFSET 0
#endif
#define OFFSET (MPOFFSET+NOCUSTOMSOFFSET)
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
#if !defined(MAKEANDPLAY)
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//Play
Add and use Game::save_exists() This is simply a shorthand for telesummary != "" || quicksummary != "", to make it easier and less error-prone to negate. This improves readability.
2020-04-26 22:41:35 +02:00
if (!game.save_exists() && !game.anything_unlocked())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//No saves exist, just start a new game
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 0;
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//Bring you to the normal playmenu
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::play);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#endif
#if !defined(NO_CUSTOM_LEVELS)
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case OFFSET+1:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//Bring you to the normal playmenu
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::playerworlds);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#endif
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case OFFSET+2:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//Options
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::graphicoptions);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case OFFSET+3:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//Options
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::options);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#if !defined(MAKEANDPLAY)
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case OFFSET+4:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//Credits
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::credits);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#else
#undef MPOFFSET
#define MPOFFSET -2
#endif
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case OFFSET+5:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//bye!
music.playef(2);
game.mainmenu = 100;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#undef OFFSET
#undef NOCUSTOMSOFFSET
#undef MPOFFSET
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
#if !defined(NO_CUSTOM_LEVELS)
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::levellist:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
if(game.currentmenuoption==(int)game.menuoptions.size()-1){
//go back to menu
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}else if(game.currentmenuoption==(int)game.menuoptions.size()-2){
Add a "previous page" option to the levels list This makes it more convenient if you have a large levels directory, as some people in the VVVVVV custom levels community do. On the first page, this option will change to be "last page" instead. Since the addition of another menu option pushes up the list of levels too close to the selected level data itself, I've had to move the list of levels down by 4 pixels (but "next page"/"previous page"/"return to menu" are still in their same position). This feature was already added to VCE but hasn't been upstreamed until now.
2020-04-17 08:05:49 +02:00
//previous page
music.playef(11);
if(game.levelpage==0){
game.levelpage=(ed.ListOfMetaData.size()-1)/8;
}else{
game.levelpage--;
}
game.createmenu(Menu::levellist, true);
game.currentmenuoption=game.menuoptions.size()-2;
map.nexttowercolour();
}else if(game.currentmenuoption==(int)game.menuoptions.size()-3){
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//next page
music.playef(11);
if((size_t) ((game.levelpage*8)+8) >= ed.ListOfMetaData.size()){
game.levelpage=0;
}else{
game.levelpage++;
}
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::levellist, true);
Add a "previous page" option to the levels list This makes it more convenient if you have a large levels directory, as some people in the VVVVVV custom levels community do. On the first page, this option will change to be "last page" instead. Since the addition of another menu option pushes up the list of levels too close to the selected level data itself, I've had to move the list of levels down by 4 pixels (but "next page"/"previous page"/"return to menu" are still in their same position). This feature was already added to VCE but hasn't been upstreamed until now.
2020-04-17 08:05:49 +02:00
game.currentmenuoption=game.menuoptions.size()-3;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}else{
//Ok, launch the level!
//PLAY CUSTOM LEVEL HOOK
music.playef(11);
game.playcustomlevel=(game.levelpage*8)+game.currentmenuoption;
game.customleveltitle=ed.ListOfMetaData[game.playcustomlevel].title;
game.customlevelfilename=ed.ListOfMetaData[game.playcustomlevel].filename;
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
std::string name = "saves/" + ed.ListOfMetaData[game.playcustomlevel].filename.substr(7) + ".vvv";
Convert custom quicksave loading attempt to TinyXML2 Seems a bit wasteful to do the whole "parse the XML document thing" instead of a simple file check. It doesn't even fail if the XML document is invalid, but whatever.
2020-06-04 02:39:21 +02:00
tinyxml2::XMLDocument doc;
if (!FILESYSTEM_loadTiXml2Document(name.c_str(), doc)){
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 22;
graphics.fademode = 2;
}else{
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::quickloadlevel);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
#endif
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::quickloadlevel:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
{
case 0: //continue save
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 23;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 22;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
Fix Menu::quickloadlevel not using returnmenu() Whoops, almost forgot this one. Now if you hit "back to levels", your position will still be kept on the selected level.
2020-04-17 21:10:07 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
#if !defined(NO_CUSTOM_LEVELS)
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::playerworlds:
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#if defined(NO_EDITOR)
#define OFFSET -1
#else
#define OFFSET 0
#endif
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
{
case 0:
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
game.levelpage=0;
ed.getDirectoryData();
game.loadcustomlevelstats(); //Should only load a file if it's needed
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::levellist);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#if !defined(NO_EDITOR)
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 1:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//LEVEL EDITOR HOOK
music.playef(11);
game.mainmenu = 20;
graphics.fademode = 2;
ed.filename="";
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#endif
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case OFFSET+2:
Add "open level folder" option to playerworlds menu This simply adds another menu option utilizing what I added in the previous commit.
2020-04-18 03:50:10 +02:00
//"OPENFOLDERHOOK"
Disable "open level folder" in Steam Big Picture mode The environment variable SteamTenfoot corresponds with the game running in Steam Big Picture mode or SteamOS if it is defined. There's a certification process for both full controller support and Big Picture mode, and being able to launch a file window in Big Picture mode is an instant cert failure.
2020-04-18 17:06:06 +02:00
if (FILESYSTEM_openDirectoryEnabled()
&& FILESYSTEM_openDirectory(FILESYSTEM_getUserLevelDirectory()))
Add "open level folder" option to playerworlds menu This simply adds another menu option utilizing what I added in the previous commit.
2020-04-18 03:50:10 +02:00
{
music.playef(11);
SDL_MinimizeWindow(graphics.screenbuffer->m_window);
}
else
{
music.playef(2);
}
break;
case OFFSET+3:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#undef OFFSET
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
#endif
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::errornostart:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::mainmenu);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::graphicoptions:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
{
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
graphics.screenbuffer->toggleFullScreen();
Add "resize to nearest" graphics option If you want your game window to simply be exactly 320x240, or 640x480, or 960x720 etc. then it's really annoying that there's no easy way to do this (to clarify, this is different from integer mode, which controls the size of the game INSIDE the window). The easiest way would be having to close the game, go into unlock.vvv, and edit the window size manually. VCE has a 1x/2x/3x/4x graphics option to solve this, although it does not account for actual monitor size (those 1x/2x/3x/4x modes are all you get, whether or not you have a monitor too small for some of them or too big for any of them to be what you want). I discussed this with flibit, and he said that VCE's approach (if it accounted for monitor size) wouldn't work on high-retina displays or high DPIs, because getting the actual multiplier to account for those monitors is kind of a pain. So the next best thing would be to add an option that resizes to the nearest perfect multiple of 320x240. That way you could simply resize the window and let the game correct any imperfect dimensions automatically.
2020-06-30 07:02:21 +02:00
// Recreate menu to update "resize to nearest"
game.createmenu(game.currentmenuname, true);
Add error messages for failed writes to disk of settings Changing settings would most of the time attempt to save unlock.vvv and now also settings.vvv, but there would be no feedback whether the files have been saved successfully or not. Now, if saving fails when changing settings in the menu, a warning message will be shown. The setting will still be applied of course, but the user will be informed it couldn't be saved. This message can be silenced until the game is restarted, because I can imagine this could get very annoying when someone already knows their settings aren't writeable. Also, some options didn't even save settings in the first place. These are turning off invincibility, and by coincidence precisely all the options in the advanced options menu. I made sure these options now do so.
2020-11-22 03:10:26 +01:00
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
graphics.screenbuffer->toggleStretchMode();
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2:
Move "resize to nearest" grouped with other resolution-related options The options for fullscreen and scaling mode were at the top, then there were various other graphical options, and then the option to resize to the nearest window size that is of an integer multiple was all the way below that. Now that last option is moved to be right below the other options related to window sizing.
2020-06-30 22:30:59 +02:00
// resize to nearest multiple
if (graphics.screenbuffer->isWindowed)
{
music.playef(11);
graphics.screenbuffer->ResizeToNearestMultiple();
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Move "resize to nearest" grouped with other resolution-related options The options for fullscreen and scaling mode were at the top, then there were various other graphical options, and then the option to resize to the nearest window size that is of an integer multiple was all the way below that. Now that last option is moved to be right below the other options related to window sizing.
2020-06-30 22:30:59 +02:00
}
else
{
music.playef(2);
}
break;
case 3:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
graphics.screenbuffer->toggleLinearFilter();
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move "resize to nearest" grouped with other resolution-related options The options for fullscreen and scaling mode were at the top, then there were various other graphical options, and then the option to resize to the nearest window size that is of an integer multiple was all the way below that. Now that last option is moved to be right below the other options related to window sizing.
2020-06-30 22:30:59 +02:00
case 4:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//change smoothing
music.playef(11);
graphics.screenbuffer->badSignalEffect= !graphics.screenbuffer->badSignalEffect;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move "resize to nearest" grouped with other resolution-related options The options for fullscreen and scaling mode were at the top, then there were various other graphical options, and then the option to resize to the nearest window size that is of an integer multiple was all the way below that. Now that last option is moved to be right below the other options related to window sizing.
2020-06-30 22:30:59 +02:00
case 5:
Add being able to toggle over/fixed-30-FPS, off by default There is now an option in "graphic options" named "toggle fps", which toggles whether the game visually runs at 1000/34 FPS or over 1000/34 FPS. It is off by default. I've had to put the entire game loop in yet another set of braces, I'll indent it next commit.
2020-05-04 21:52:57 +02:00
//toggle 30+ fps
music.playef(11);
game.over30mode = !game.over30mode;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Add being able to toggle over/fixed-30-FPS, off by default There is now an option in "graphic options" named "toggle fps", which toggles whether the game visually runs at 1000/34 FPS or over 1000/34 FPS. It is off by default. I've had to put the entire game loop in yet another set of braces, I'll indent it next commit.
2020-05-04 21:52:57 +02:00
break;
Move "resize to nearest" grouped with other resolution-related options The options for fullscreen and scaling mode were at the top, then there were various other graphical options, and then the option to resize to the nearest window size that is of an integer multiple was all the way below that. Now that last option is moved to be right below the other options related to window sizing.
2020-06-30 22:30:59 +02:00
case 6:
Add VSync graphics option, off by default This is if you want delta-timesteps to go as quickly as possible. Also it seems like on Windows this only has an effect in exclusive fullscreen mode.
2020-05-04 22:19:47 +02:00
//toggle vsync
music.playef(11);
Haiku: Keep the option visible, but note the bug
2020-07-08 20:43:04 +02:00
#ifndef __HAIKU__ // FIXME: Remove after SDL VSync bug is fixed! -flibit
Move the VSync work to Screen. The problem we're running into is entirely contained in the Screen - we need to either decouple graphics context init from Screen::init or we need to take out the screenbuffer interaction from loadstats (which I'm more in favor of since we can just pull the config values and pass them to Screen::init later).
2020-07-02 06:19:40 +02:00
graphics.screenbuffer->vsync = !graphics.screenbuffer->vsync;
graphics.screenbuffer->resetRendererWorkaround();
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
More VSync Haiku hackery
2020-07-08 20:38:55 +02:00
#endif
Haiku: Keep the option visible, but note the bug
2020-07-08 20:43:04 +02:00
break;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Make returning from game/graphic options return to MAPMODE This is so return doesn't just lead back to more TITLEMODE.
2020-06-23 01:51:16 +02:00
if (game.ingame_titlemode)
{
Move returning to pause menu code to separate function This code is getting a bit more complicated now, we should maybe stop copy-pasting it everywhere.
2020-06-23 02:26:45 +02:00
game.returntopausemenu();
Make returning from game/graphic options return to MAPMODE This is so return doesn't just lead back to more TITLEMODE.
2020-06-23 01:51:16 +02:00
}
else
{
Save current menu to temp variable when entering options from in-game This is to pre-emptively prevent piling up stack frames for what I'll be adding next, which is pressing Esc in the options menu in-game automatically moving you back to MAPMODE.
2020-06-23 02:23:56 +02:00
game.returnmenu();
Make returning from game/graphic options return to MAPMODE This is so return doesn't just lead back to more TITLEMODE.
2020-06-23 01:51:16 +02:00
map.nexttowercolour();
}
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::youwannaquit:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//bye!
music.playef(2);
game.mainmenu = 100;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
Fix being able to mismatch summary and menu color You were able to mismatch the color of the quicksave/telesave summary and the text/background by pressing Esc when in the "continue" menu, then pressing ACTION on "no, return". This commit fixes that bug by putting the map.settowercolour(3) inside the Menu::continuemenu creation code itself. However, since the Menu::youwannaquit code does map.nexttowercolour() right after it does the game.createmenu(), we also need to put the map.nexttowercolour() before the game.createmenu() beforehand so it doesn't mess up the cyan color that Menu::continuemenu sets. Additionally, I removed the map.settowercolour() from the input handling of Menu::play, as it's superfluous.
2020-04-17 04:52:39 +02:00
map.nexttowercolour(); //This goes first, otherwise mismatching continuemenu color is possible
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::setinvincibility:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.invincibility = !map.invincibility;
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Rename Menu::setslowdown2 to Menu::setslowdown Now that setslowdown1 has been removed it's no longer necessary to have a 2 on the end of setslowdown2.
2020-04-17 01:02:01 +02:00
case Menu::setslowdown:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
game.slowdown = 30;
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.slowdown = 24;
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.slowdown = 18;
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 3:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.slowdown = 12;
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
case Menu::advancedoptions:
switch (game.currentmenuoption)
{
case 0:
//toggle mouse cursor
music.playef(11);
if (graphics.showmousecursor == true) {
SDL_ShowCursor(SDL_DISABLE);
graphics.showmousecursor = false;
}
else {
SDL_ShowCursor(SDL_ENABLE);
graphics.showmousecursor = true;
}
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
break;
case 1:
// toggle unfocus pause
game.disablepause = !game.disablepause;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
music.playef(11);
break;
case 2:
// toggle fake load screen
game.skipfakeload = !game.skipfakeload;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
music.playef(11);
break;
case 3:
// toggle translucent roomname BG
graphics.translucentroomname = !graphics.translucentroomname;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
music.playef(11);
break;
case 4:
// Glitchrunner mode
music.playef(11);
game.glitchrunnermode = !game.glitchrunnermode;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
break;
case 5:
//back
music.playef(11);
game.returnmenu();
map.nexttowercolour();
break;
}
break;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::accessibility:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//disable animated backgrounds
game.colourblindmode = !game.colourblindmode;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Refactor tower background to use a separate object instead Previously, the tower background was controlled by a disparate set of attributes on Graphics and mapclass, and wasn't really encapsulated. (If that's what that word means, I don't particularly care about object-oriented lingo.) But now, all relevant things that a tower background has has been put into a TowerBG struct, so it will be easy to make multiple copies without having to duplicate the code that handles it.
2020-11-03 00:05:24 +01:00
graphics.towerbg.tdrawback = true;
Move title usages of towerbg to titlebg With the previous commit in place, we can now simply move some usages of the previous towerbg to use a separate object instead. That way, we don't have to mess with a monolithic state, or some better way to phrase what I just said, and we instead have two separate objects that can coexist side-by-side.
2020-11-03 00:23:53 +01:00
graphics.titlebg.tdrawback = true;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//disable screeneffects
game.noflashingmode = !game.noflashingmode;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
if (!game.noflashingmode)
{
music.playef(18);
game.screenshake = 10;
game.flashlight = 5;
}else{
music.playef(11);
}
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//disable text outline
graphics.notextoutline = !graphics.notextoutline;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 3:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//invincibility
Allow toggling invincibility/slowdown in intermission replays inspecial() includes being in intermission replays, but it's not necessary to disable invincibility/slowdown for them.
2020-06-23 07:55:59 +02:00
if (!game.ingame_titlemode || (!game.insecretlab && !game.intimetrial && !game.nodeathmode))
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Prevent turning on invincibility/slowdown in in-game options menu Would've been the easiest exploit ever! But I gotta patch it.
2020-06-23 02:37:53 +02:00
if (!map.invincibility)
{
game.createmenu(Menu::setinvincibility);
map.nexttowercolour();
}
else
{
map.invincibility = !map.invincibility;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Prevent turning on invincibility/slowdown in in-game options menu Would've been the easiest exploit ever! But I gotta patch it.
2020-06-23 02:37:53 +02:00
}
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
else
{
Prevent turning on invincibility/slowdown in in-game options menu Would've been the easiest exploit ever! But I gotta patch it.
2020-06-23 02:37:53 +02:00
music.playef(2);
map.invincibility = false;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 4:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//change game speed
Only check Secret Lab/Time Trial/NDM for slowdown if ingame_titlemode This is already done for invincibility. It's kind of unnecessary, but it's just to make sure if for some reason in the future variables like insecretlab/intimetrial/nodeathmode don't get reset when exiting to the menu.
2020-06-23 07:56:40 +02:00
if (!game.ingame_titlemode || (!game.insecretlab && !game.intimetrial && !game.nodeathmode))
Prevent turning on invincibility/slowdown in in-game options menu Would've been the easiest exploit ever! But I gotta patch it.
2020-06-23 02:37:53 +02:00
{
game.createmenu(Menu::setslowdown);
map.nexttowercolour();
music.playef(11);
}
else
{
music.playef(2);
Remove game.gameframerate as duplicate of game.slowdown game.gameframerate seems to exist for converting the value of game.slowdown into an actual timestep value, when really the timestep value should just use game.slowdown directly with a fast lookup table. Otherwise, there's a bunch of duplicated game.slowdown case-switches everywhere, which adds up to a large, annoying pile should the values be changed in the future. But now the duplicate variable has been removed, and with it, all the copy-pasted case-switches. Also, the game speed text rendering in Menu::accessibility and Menu::setslowdown has been factored out to a function and de-duplicated as well.
2020-11-13 02:05:18 +01:00
game.slowdown = 30;
Prevent turning on invincibility/slowdown in in-game options menu Would've been the easiest exploit ever! But I gotta patch it.
2020-06-23 02:37:53 +02:00
}
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 5:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//Can't do yet! play sad sound
music.playef(2);
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::options:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
#if defined(MAKEANDPLAY)
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
int flipmode_offset = 0;
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#else
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
int flipmode_offset = game.ingame_titlemode && game.unlock[18] ? 0 : -1;
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#endif
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
#if defined(MAKEANDPLAY)
int unlockmode_offset = -1;
#else
int unlockmode_offset = 0;
#endif
int mmmmmm_offset = music.mmmmmm ? 0 : -1;
int offset = 0;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//accessibility options
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::accessibility);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
//advanced options
Add glitchrunner mode, in game options Glitchrunner mode is intended to re-enable glitches that existed in older versions of VVVVVV. These glitches were removed because they could legitimately affect a casual player's experience. Glitches like various R-pressing screwery, Space Station 1 skip, telejumping, Gravitron out-of-bounds, etc. will not be patched.
2020-06-25 23:31:37 +02:00
music.playef(11);
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
game.createmenu(Menu::advancedoptions);
map.nexttowercolour();
Add glitchrunner mode, in game options Glitchrunner mode is intended to re-enable glitches that existed in older versions of VVVVVV. These glitches were removed because they could legitimately affect a casual player's experience. Glitches like various R-pressing screwery, Space Station 1 skip, telejumping, Gravitron out-of-bounds, etc. will not be patched.
2020-06-25 23:31:37 +02:00
break;
case 2:
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
#if !defined(MAKEANDPLAY)
if (game.ingame_titlemode && game.unlock[18])
#endif
{
// toggle Flip Mode
graphics.setflipmode = !graphics.setflipmode;
Remove game.savemystats This variable seems to have been intended to make sure game.savestatsandsettings() was called at the end of the frame, or make sure that it didn't get called more than once per frame. I don't see any frame ordering-related reason why it needs to be called specifically at the end of the frame (the function doesn't modify any state), so it's more plausible that it was added to make sure it didn't get called more than one per frame. However, upon further analysis, none of the code paths where game.savemystats is used ever calls or sets game.savemystats more than once, and a majority of the code directly calls game.savestatsandsettings() anyway, so there's no reason for this variable to exist. If we ever need to make sure it doesn't get called more than once, and there's no way to change the code paths around to prevent it otherwise, we can use the defer callbacks system that I added to #535, when it gets merged.
2021-01-11 04:39:19 +01:00
game.savestatsandsettings();
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
if (graphics.setflipmode)
{
music.playef(18);
game.screenshake = 10;
game.flashlight = 5;
}
else
{
music.playef(11);
}
Fix wrong Tower music when toggling Flip Mode from in-game options The music for the Tower is supposed to be ecroF evitisoP in Flip Mode, and Positive Force when not in Flip Mode. However, if you go to the options from the pause menu and toggle Flip Mode, the music isn't changed. Fixing this is pretty simple, just check the current area if not in a custom level and play the correct track accordingly when toggling Flip Mode from in-game.
2020-07-11 01:55:56 +02:00
// Fix wrong area music in Tower (Positive Force vs. ecroF evitisoP)
if (map.custommode)
{
break;
}
int area = map.area(game.roomx, game.roomy);
if (area == 3 || area == 11)
{
if (graphics.setflipmode)
{
music.play(9); // ecroF evitisoP
}
else
{
music.play(2); // Positive Force
}
}
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
}
break;
}
offset += flipmode_offset;
#if !defined(MAKEANDPLAY)
if (game.currentmenuoption == 3+offset)
{
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//unlock play options
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::unlockmenu);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
}
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
#endif
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
offset += unlockmode_offset;
if (game.currentmenuoption == 4+offset)
{
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//clear data menu
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::controller);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
}
else if (game.currentmenuoption == 5+offset)
{
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//clear data menu
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::cleardatamenu);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
else if (game.currentmenuoption == 6+offset && music.mmmmmm)
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
{
//**** TOGGLE MMMMMM
music.usingmmmmmm = !music.usingmmmmmm;
music.playef(11);
Fix toggling MMMMMM always playing Presenting VVVVVV This would be fine, under the assumption that you could never reach the menu from outside the menu. Well, now you can, so now this has to play the correct song instead of track 6.
2020-06-23 02:44:03 +02:00
music.play(music.currentsong);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
offset += mmmmmm_offset;
if (game.currentmenuoption == 7+offset)
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
{
//back
music.playef(11);
Make returning from game/graphic options return to MAPMODE This is so return doesn't just lead back to more TITLEMODE.
2020-06-23 01:51:16 +02:00
if (game.ingame_titlemode)
{
Move returning to pause menu code to separate function This code is getting a bit more complicated now, we should maybe stop copy-pasting it everywhere.
2020-06-23 02:26:45 +02:00
game.returntopausemenu();
Make returning from game/graphic options return to MAPMODE This is so return doesn't just lead back to more TITLEMODE.
2020-06-23 01:51:16 +02:00
}
else
{
Save current menu to temp variable when entering options from in-game This is to pre-emptively prevent piling up stack frames for what I'll be adding next, which is pressing Esc in the options menu in-game automatically moving you back to MAPMODE.
2020-06-23 02:23:56 +02:00
game.returnmenu();
Make returning from game/graphic options return to MAPMODE This is so return doesn't just lead back to more TITLEMODE.
2020-06-23 01:51:16 +02:00
map.nexttowercolour();
}
De-duplicate copy-pasted input/render code in menus This removes duplicate code that came about as a result of various possible permutations of menu options, depending on being M&P, having no custom level support, having no editor support, and having MMMMMM. The menus with such permutations are the following: - main menu - "start game" is gone in MAKEANDPLAY - "player levels" is gone in NO_CUSTOM_LEVELS - "view credits" is gone in MAKEANDPLAY - "game options" - "unlock play data" is gone in MAKEANDPLAY - "soundtrack" is gone if you don't have an mmmmmm.vvv file - "player levels" - "level editor" is gone in NO_EDITOR I achieve this de-duplication by clever use of calculating offsets, which I feel is the best way to de-duplicate the code with the least amount of work, if a little brittle. The other options are to (1) put function pointers on each MenuOption object, which is pretty verbose and would inflate Game::createmenu() by a lot, (2) switch all game.currentmenuoption checks to instead check for the text of the currently-selected menu option, which is very error-prone because if you make a typo it won't be caught at compile-time, (3) add a unique ID to each MenuOption object that represents a text but will error at compile-time if you make a typo, however this just duplicates all the menu option text, which is more code than was duplicated previously. So I just went with this one.
2020-04-16 02:59:03 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::unlockmenutrials:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0: //unlock 1
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.unlock[9] = true;
game.unlocknotify[9] = true;
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenutrials, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1: //unlock 2
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.unlock[10] = true;
game.unlocknotify[10] = true;
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenutrials, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2: //unlock 3
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.unlock[11] = true;
game.unlocknotify[11] = true;
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenutrials, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 3: //unlock 4
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.unlock[12] = true;
game.unlocknotify[12] = true;
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenutrials, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 4: //unlock 5
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.unlock[13] = true;
game.unlocknotify[13] = true;
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenutrials, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 5: //unlock 6
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.unlock[14] = true;
game.unlocknotify[14] = true;
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenutrials, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 6: //back
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::unlockmenu:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//unlock time trials separately...
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::unlockmenutrials);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//unlock intermissions
music.playef(11);
game.unlock[16] = true;
game.unlocknotify[16] = true;
game.unlock[6] = true;
game.unlock[7] = true;
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenu, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//unlock no death mode
music.playef(11);
game.unlock[17] = true;
game.unlocknotify[17] = true;
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenu, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 3:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//unlock flip mode
music.playef(11);
game.unlock[18] = true;
game.unlocknotify[18] = true;
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenu, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 4:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//unlock jukebox
music.playef(11);
game.stat_trinkets = 20;
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenu, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 5:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//unlock secret lab
music.playef(11);
game.unlock[8] = true;
game.unlocknotify[8] = true;
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::unlockmenu, true);
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//next page
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::credits2, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
case 1:
//last page
music.playef(11);
game.createmenu(Menu::credits6, true);
map.nexttowercolour();
break;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits2:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//next page
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::credits25, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
//previous page
music.playef(11);
game.createmenu(Menu::credits, true);
map.nexttowercolour();
break;
case 2:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits25:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//next page
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::credits3, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
case 1:
//previous page
music.playef(11);
game.createmenu(Menu::credits2, true);
map.nexttowercolour();
break;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits3:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//next page
music.playef(11);
game.current_credits_list_index += 9;
Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
if (game.current_credits_list_index >= (int)SDL_arraysize(Credits::superpatrons))
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
// No more super patrons. Move to the next credits section
game.current_credits_list_index = 0;
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::credits4, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
else
{
// There are more super patrons. Refresh the menu with the next ones
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::credits3, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
map.nexttowercolour();
break;
case 1:
//previous page
music.playef(11);
game.current_credits_list_index -= 9;
if (game.current_credits_list_index < 0)
{
//No more super patrons. Move to the previous credits section
game.current_credits_list_index = 0;
game.createmenu(Menu::credits25, true);
}
else
{
//There are more super patrons. Refresh the menu with the next ones
game.createmenu(Menu::credits3, true);
}
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
game.current_credits_list_index = 0;
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits4:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//next page
music.playef(11);
game.current_credits_list_index += 14;
Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
if (game.current_credits_list_index >= (int)SDL_arraysize(Credits::patrons))
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
// No more patrons. Move to the next credits section
game.current_credits_list_index = 0;
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::credits5, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
else
{
// There are more patrons. Refresh the menu with the next ones
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::credits4, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
map.nexttowercolour();
break;
case 1:
//previous page
music.playef(11);
game.current_credits_list_index -= 14;
if (game.current_credits_list_index < 0)
{
//No more patrons. Move to the previous credits section
Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
game.current_credits_list_index = SDL_arraysize(Credits::superpatrons) - 1 - (SDL_arraysize(Credits::superpatrons)-1)%9;
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
game.createmenu(Menu::credits3, true);
}
else
{
//There are more patrons. Refresh the menu with the next ones
game.createmenu(Menu::credits4, true);
}
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
game.current_credits_list_index = 0;
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits5:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//next page
music.playef(11);
game.current_credits_list_index += 9;
Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
if (game.current_credits_list_index >= (int)SDL_arraysize(Credits::githubfriends))
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
// No more GitHub contributors. Move to the next credits section
game.current_credits_list_index = 0;
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::credits6, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
else
{
// There are more GitHub contributors. Refresh the menu with the next ones
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::credits5, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
map.nexttowercolour();
break;
case 1:
//previous page
music.playef(11);
game.current_credits_list_index -= 9;
if (game.current_credits_list_index < 0)
{
//No more GitHub contributors. Move to the previous credits section
Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
game.current_credits_list_index = SDL_arraysize(Credits::patrons) - 1 - (SDL_arraysize(Credits::patrons)-1)%14;
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
game.createmenu(Menu::credits4, true);
}
else
{
//There are more GitHub contributors. Refresh the menu with the next ones
game.createmenu(Menu::credits5, true);
}
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
game.current_credits_list_index = 0;
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits6:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//first page
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::credits, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
case 1:
//previous page
music.playef(11);
Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
game.current_credits_list_index = SDL_arraysize(Credits::githubfriends) - 1 - (SDL_arraysize(Credits::githubfriends)-1)%9;
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
game.createmenu(Menu::credits5, true);
map.nexttowercolour();
break;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::play:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
De-duplicate "secret lab" menu option in "play" menu Instead of creating an entirely new menu for it, just dynamically add the Secret Lab menu option as needed.
2020-04-16 04:38:42 +02:00
//Do we have the Secret Lab option?
Make "start game" goto play menu if any unlocks, even if saves deleted This commit fixes a slightly frustrating thing where if you start a new game, and then exit before saving, "start game" will always take you to a new game, even though you have unlocked things like the Secret Lab or Time Trials. Now, if you select "new game" (only possible if you have something unlocked), then quit before saving, "start game" will still take you to the play menu, but "continue" is replaced with "start" and "new game" is gone.
2020-04-26 22:09:56 +02:00
int sloffset = game.unlock[8] ? 0 : -1;
//Do we have a telesave or quicksave?
Add and use Game::save_exists() This is simply a shorthand for telesummary != "" || quicksummary != "", to make it easier and less error-prone to negate. This improves readability.
2020-04-26 22:41:35 +02:00
int ngoffset = game.save_exists() ? 0 : -1;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
if (game.currentmenuoption == 0)
{
//continue
//right, this depends on what saves you've got
Add and use Game::save_exists() This is simply a shorthand for telesummary != "" || quicksummary != "", to make it easier and less error-prone to negate. This improves readability.
2020-04-26 22:41:35 +02:00
if (!game.save_exists())
Make "start game" goto play menu if any unlocks, even if saves deleted This commit fixes a slightly frustrating thing where if you start a new game, and then exit before saving, "start game" will always take you to a new game, even though you have unlocked things like the Secret Lab or Time Trials. Now, if you select "new game" (only possible if you have something unlocked), then quit before saving, "start game" will still take you to the play menu, but "continue" is replaced with "start" and "new game" is gone.
2020-04-26 22:09:56 +02:00
{
//You have no saves but have something unlocked, or you couldn't have gotten here
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Make "start game" goto play menu if any unlocks, even if saves deleted This commit fixes a slightly frustrating thing where if you start a new game, and then exit before saving, "start game" will always take you to a new game, even though you have unlocked things like the Secret Lab or Time Trials. Now, if you select "new game" (only possible if you have something unlocked), then quit before saving, "start game" will still take you to the play menu, but "continue" is replaced with "start" and "new game" is gone.
2020-04-26 22:09:56 +02:00
game.mainmenu = 0;
graphics.fademode = 2;
}
else if (game.telesummary == "")
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
//You at least have a quicksave, or you couldn't have gotten here
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 2;
graphics.fademode = 2;
}
else if (game.quicksummary == "")
{
//You at least have a telesave, or you couldn't have gotten here
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 1;
graphics.fademode = 2;
}
else
{
//go to a menu!
music.playef(11);
game.loadsummary(); //Prepare save slots to display
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::continuemenu);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
}
De-duplicate "secret lab" menu option in "play" menu Instead of creating an entirely new menu for it, just dynamically add the Secret Lab menu option as needed.
2020-04-16 04:38:42 +02:00
else if (game.currentmenuoption == 1 && game.unlock[8])
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Prevent selecting Secret Lab if game isn't at full speed The game won't let you select the Secret Lab if you're in invincibility mode, probably so you can't set illegitimate Super Gravitron records just by standing there and doing nothing. However, for some reason, it'll still let you select the Secret Lab even if you've slowed down the game. For consistency, let's prevent selecting the Secret Lab if the game isn't running at fullspeed, too.
2020-04-16 05:17:36 +02:00
if(!map.invincibility && game.slowdown == 30){
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 11;
graphics.fademode = 2;
}else{
//Can't do yet! play sad sound
music.playef(2);
}
}
Make "start game" goto play menu if any unlocks, even if saves deleted This commit fixes a slightly frustrating thing where if you start a new game, and then exit before saving, "start game" will always take you to a new game, even though you have unlocked things like the Secret Lab or Time Trials. Now, if you select "new game" (only possible if you have something unlocked), then quit before saving, "start game" will still take you to the play menu, but "continue" is replaced with "start" and "new game" is gone.
2020-04-26 22:09:56 +02:00
else if (game.currentmenuoption == sloffset+2)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
//play modes
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::playmodes);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
Add and use Game::save_exists() This is simply a shorthand for telesummary != "" || quicksummary != "", to make it easier and less error-prone to negate. This improves readability.
2020-04-26 22:41:35 +02:00
else if (game.currentmenuoption == sloffset+3 && game.save_exists())
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
//newgame
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::newgamewarning);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
Make "start game" goto play menu if any unlocks, even if saves deleted This commit fixes a slightly frustrating thing where if you start a new game, and then exit before saving, "start game" will always take you to a new game, even though you have unlocked things like the Secret Lab or Time Trials. Now, if you select "new game" (only possible if you have something unlocked), then quit before saving, "start game" will still take you to the play menu, but "continue" is replaced with "start" and "new game" is gone.
2020-04-26 22:09:56 +02:00
else if (game.currentmenuoption == sloffset+ngoffset+4)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::newgamewarning:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//yep
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 0;
graphics.fademode = 2;
game.deletequick();
game.deletetele();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::controller:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Remove duplicate game.controllerSensitivity proxy It wasn't a direct duplicate of key.sensitivity, but it was still basically the same thing. Although to be fair, at least the case-switch conversion didn't get duplicated everywhere unlike game.slowdown. So now key.sensitivity functions the same as game.controllerSensitivity, and it only gets converted to its actual value whenever a joystick input happens in key.Poll(), unlike previously where it got converted every single frame on the title screen (there was even a comment that said "TODO bit wasteful doing this every poll").
2020-11-13 02:16:18 +01:00
key.sensitivity++;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
Remove duplicate game.controllerSensitivity proxy It wasn't a direct duplicate of key.sensitivity, but it was still basically the same thing. Although to be fair, at least the case-switch conversion didn't get duplicated everywhere unlike game.slowdown. So now key.sensitivity functions the same as game.controllerSensitivity, and it only gets converted to its actual value whenever a joystick input happens in key.Poll(), unlike previously where it got converted every single frame on the title screen (there was even a comment that said "TODO bit wasteful doing this every poll").
2020-11-13 02:16:18 +01:00
if(key.sensitivity > 4)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Remove duplicate game.controllerSensitivity proxy It wasn't a direct duplicate of key.sensitivity, but it was still basically the same thing. Although to be fair, at least the case-switch conversion didn't get duplicated everywhere unlike game.slowdown. So now key.sensitivity functions the same as game.controllerSensitivity, and it only gets converted to its actual value whenever a joystick input happens in key.Poll(), unlike previously where it got converted every single frame on the title screen (there was even a comment that said "TODO bit wasteful doing this every poll").
2020-11-13 02:16:18 +01:00
key.sensitivity = 0;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
game.savestatsandsettings_menu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
Added ability to bind restart to a controller.
2020-08-09 00:41:59 +02:00
case 5:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Fix returning from game pad options not updating tower color I was looking through all calls to game.returnmenu(), and I noticed that the return option in the game pad screen didn't have a map.nexttowercolour(). I tested it and, yep, returning from there doesn't update the background color. So that should be fixed now.
2021-03-05 09:54:25 +01:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::cleardatamenu:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
default:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//yep
music.playef(23);
game.deletequick();
game.deletetele();
game.deletestats();
Move all settings to settings.vvv The game previously did this dumb thing where it lumped in all its settings with its file that tracked your records and unlocks, `unlock.vvv`. It wasn't really an issue, until 2.3 came along and added a few settings, suddenly making a problem where 2.3 settings would be reset by chance if you decided to touch 2.2. The solution to this is to move all settings to a new file, `settings.vvv`. However, for compatibility with 2.2, settings will still be written to `unlock.vvv`. The game will prioritize reading from `settings.vvv` instead of `unlock.vvv`, so if there's a setting that's missing from `unlock.vvv`, no worries there. But if `settings.vvv` is missing, then it'll read settings from `unlock.vvv`. As well, if `unlock.vvv` is missing, then `settings.vvv` will be read from instead (I explicitly tested for this, and found that I had to write special code to handle this case, otherwise the game would overwrite the existing `settings.vvv` before reading from it; kids, make sure to always test your code!). Closes #373 fully.
2020-11-04 08:11:21 +01:00
game.deletesettings();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.flashlight = 5;
game.screenshake = 15;
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::mainmenu);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::playmodes:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
if (game.currentmenuoption == 0 && game.slowdown == 30 && !map.invincibility) //go to the time trial menu
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::timetrials);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
else if (game.currentmenuoption == 1 && game.unlock[16])
{
//intermission mode menu
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::intermissionmenu);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
else if (game.currentmenuoption == 2 && game.unlock[17] && game.slowdown == 30 && !map.invincibility) //start a game in no death mode
{
music.playef(11);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::startnodeathmode);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
else if (game.currentmenuoption == 3 && game.unlock[18]) //enable/disable flip mode
{
Add Flip Mode to game options if in M&P or in-game menu and unlocked Flip Mode will now be in the game options menu if either: (1) You're playing the M&P version. (2) You have it unlocked and you came here from the in-game pause screen. This is because if you're playing M&P, you'd have to close the game, edit unlock.vvv, and re-launch the game to toggle Flip Mode, since there's no other way to do so. And if you're playing the full version, you'd have to save and exit your session in order to toggle Flip Mode.
2020-06-30 05:45:57 +02:00
// WARNING: Partially duplicated in Menu::options
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
graphics.setflipmode = !graphics.setflipmode;
Remove game.savemystats This variable seems to have been intended to make sure game.savestatsandsettings() was called at the end of the frame, or make sure that it didn't get called more than once per frame. I don't see any frame ordering-related reason why it needs to be called specifically at the end of the frame (the function doesn't modify any state), so it's more plausible that it was added to make sure it didn't get called more than one per frame. However, upon further analysis, none of the code paths where game.savemystats is used ever calls or sets game.savemystats more than once, and a majority of the code directly calls game.savestatsandsettings() anyway, so there's no reason for this variable to exist. If we ever need to make sure it doesn't get called more than once, and there's no way to change the code paths around to prevent it otherwise, we can use the defer callbacks system that I added to #535, when it gets merged.
2021-01-11 04:39:19 +01:00
game.savestatsandsettings();
Only flash and shake screen when enabling Flip Mode It's a bit inconsistent how every time you toggle flip mode, it does this flashing and shaking (and different SFX), regardless of whether or not you're turning it on or off. To be more consistent with what happens when you toggle screen effects, only turning on Flip Mode should do the flashing/shaking/game-saved sound, and turning it off should just play the Viridian squeak.
2020-05-19 03:09:12 +02:00
if (graphics.setflipmode)
{
music.playef(18);
game.screenshake = 10;
game.flashlight = 5;
}
else
{
music.playef(11);
}
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
else if (game.currentmenuoption == 4)
{
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
else
{
//Can't do yet! play sad sound
music.playef(2);
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::startnodeathmode:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0: //start no death mode, disabling cutscenes
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 10;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 9;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::continuemenu:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 1;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 2;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::intermissionmenu:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
music.play(6);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::playint1);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
music.playef(11);
music.play(6);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::playint2);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::playint1:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 12;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 13;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 14;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 3:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 15;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 4:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::playint2:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 16;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 17;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 2:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 18;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 3:
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 19;
graphics.fademode = 2;
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 4:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::gameover2:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
music.play(6);
Fix exiting No Death Mode being one menu too far back I want exiting No Death Mode to go back to the "play modes" menu, not to the "start game" menu, because it's too far back. Also do the same if you either die or complete No Death Mode. Also I initialized Game::wasinintermission, probably a good thing to initialize variables.
2020-04-27 21:27:12 +02:00
game.returntomenu(Menu::playmodes);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::unlocktimetrials:
case Menu::unlocktimetrial:
case Menu::unlocknodeathmode:
case Menu::unlockintermission:
case Menu::unlockflipmode:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
Mark same menus in levels list, credits, and unlock menus This marks pressing ACTION on "next page" in the levels list, credits, pressing ACTION on "continue" in "You have unlocked" menus, and pressing ACTION on an unlock option in the unlock menu and time trial unlock menu as being the same menu. This is to prevent creating unnecessary stack frames when using said menu options in those menus.
2020-04-17 04:26:49 +02:00
game.createmenu(Menu::play, true);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::timetrials:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
if (game.currentmenuoption == 0 && game.unlock[9]) //space station 1
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 3;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 1 && game.unlock[10]) //lab
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 4;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 2 && game.unlock[11]) //tower
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 5;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 3 && game.unlock[12]) //station 2
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 6;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 4 && game.unlock[13]) //warp
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 7;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 5 && game.unlock[14]) //final
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 8;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 6) //go to the time trial menu
{
//back
music.playef(11);
Use game.returnmenu() for all "return" menu options This is to not reset your cursor position every time you return on something. It's also to automatically keep track of which menu was the previous menu instead of manually hardcoding said previous menu.
2020-04-17 05:05:01 +02:00
game.returnmenu();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
}
else
{
//Can't do yet! play sad sound
music.playef(2);
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::timetrialcomplete3:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
switch (game.currentmenuoption)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
case 0:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//back
music.playef(11);
music.play(6);
Use returntomenu(timetrials) instead of returnmenu in timetrialcomplete3 This fixes a corner case where using gamestate 82 from the editor would put you in a softlock because it would return to the editor settings menu, which only functions in EDITORMODE and results in a softlock in TITLEMODE.
2020-06-26 01:22:58 +02:00
game.returntomenu(Menu::timetrials);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
map.nexttowercolour();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
case 1:
Don't go to main menu when exiting to menu This also replaces some createmenu()s with returnmenu()s as needed even when said createmenu()s already didn't go to the main menu. Now when you exit the level editor, you'll be selecting the "level editor" option in "play levels", and if you exit from a level you'll still be selecting that level in the levels list. Furthermore, regardless of what you're exiting, your cursor position will be remembered.
2020-04-17 06:25:30 +02:00
//Ok but first quickly remove the last stack frame to prevent piling up timetrialcomplete stack frames
if (game.menustack.empty())
{
puts("Error: menu stack is empty!");
}
else
{
game.menustack.pop_back();
}
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//duplicate the above based on given time trial level!
if (game.timetriallevel == 0) //space station 1
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 3;
graphics.fademode = 2;
}
else if (game.timetriallevel == 1) //lab
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 4;
graphics.fademode = 2;
}
else if (game.timetriallevel == 2) //tower
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 5;
graphics.fademode = 2;
}
else if (game.timetriallevel == 3) //station 2
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 6;
graphics.fademode = 2;
}
else if (game.timetriallevel == 4) //warp
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 7;
graphics.fademode = 2;
}
else if (game.timetriallevel == 5) //final
{
Make all gamemode starts play a Viridan squeak It's always personally irked me that the only time you get a Viridian squeak when pressing ACTION to start fading out and going in-game is when you start playing a custom level. And that's only if you don't have a quicksave. To make things more consistent (and to add more polish to the game), I made sure there was a music.playef(11) every time game.mainmenu gets set. I also made sure that this doesn't result in double-squeaking, i.e. music.playef(11) being called twice, which can be very loud and ear-hurting.
2020-05-19 03:03:18 +02:00
music.playef(11);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.mainmenu = 8;
graphics.fademode = 2;
}
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::gamecompletecontinue:
case Menu::nodeathmodecomplete2:
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
music.play(6);
music.playef(11);
Don't go to main menu when exiting to menu This also replaces some createmenu()s with returnmenu()s as needed even when said createmenu()s already didn't go to the main menu. Now when you exit the level editor, you'll be selecting the "level editor" option in "play levels", and if you exit from a level you'll still be selecting that level in the levels list. Furthermore, regardless of what you're exiting, your cursor position will be remembered.
2020-04-17 06:25:30 +02:00
game.returnmenu();
Use case-switch for menu options where possible I've converted every "else if"-chain in menu render/input code to be a case-switch, except for the levels list, the "game options" menu (because it has the MMMMMM menu option which isn't a compile-time constant), and the "play" menu (because it has the Secret Lab menu option which also isn't a compile-time option). I also did NOT convert some case-switches relating to unlocks in Input.cpp, mostly because they use a system where the "if we have this unlocked" conditional is a part of the "if this is the current menu option" conditional, and they use the 'else' branch to play a sad sound if that "if we have this unlocked" conditional fails. I've also converted the game.gameframerate and game.crewrescued() "else if"-chains to be case-switches instead.
2020-04-16 05:10:11 +02:00
map.nexttowercolour();
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Add error messages for failed writes to disk of settings Changing settings would most of the time attempt to save unlock.vvv and now also settings.vvv, but there would be no feedback whether the files have been saved successfully or not. Now, if saving fails when changing settings in the menu, a warning message will be shown. The setting will still be applied of course, but the user will be informed it couldn't be saved. This message can be silenced until the game is restarted, because I can imagine this could get very annoying when someone already knows their settings aren't writeable. Also, some options didn't even save settings in the first place. These are turning off invincibility, and by coincidence precisely all the options in the advanced options menu. I made sure these options now do so.
2020-11-22 03:10:26 +01:00
case Menu::errorsavingsettings:
if (game.currentmenuoption == 1)
{
game.silence_settings_error = true;
}
music.playef(11);
game.returnmenu();
map.nexttowercolour();
break;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
default:
break;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
}
Use dynamic credits lists for main menu credits screens (and add GitHub contributors) (#160) Also added GitHub contributors to the credits on the main menu (previously they were only present in the credits at the end of the game)
2020-02-12 05:45:58 +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 titleinput(void)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
//game.mx = (mouseX / 4);
//game.my = (mouseY / 4);
Use dynamic credits lists for main menu credits screens (and add GitHub contributors) (#160) Also added GitHub contributors to the credits on the main menu (previously they were only present in the credits at the end of the game)
2020-02-12 05:45:58 +01:00
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
game.press_left = false;
game.press_right = false;
game.press_action = false;
game.press_map = false;
Use dynamic credits lists for main menu credits screens (and add GitHub contributors) (#160) Also added GitHub contributors to the credits on the main menu (previously they were only present in the credits at the end of the game)
2020-02-12 05:45:58 +01:00
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
if (graphics.flipmode)
{
if (key.isDown(KEYBOARD_LEFT) || key.isDown(KEYBOARD_DOWN) || key.isDown(KEYBOARD_a) || key.isDown(KEYBOARD_s) || key.controllerWantsRight(true)) game.press_left = true;
if (key.isDown(KEYBOARD_RIGHT) || key.isDown(KEYBOARD_UP) || key.isDown(KEYBOARD_d) || key.isDown(KEYBOARD_w) || key.controllerWantsLeft(true)) game.press_right = true;
}
else
{
if (key.isDown(KEYBOARD_LEFT) || key.isDown(KEYBOARD_UP) || key.isDown(KEYBOARD_a) || key.isDown(KEYBOARD_w) || key.controllerWantsLeft(true))
{
game.press_left = true;
}
if (key.isDown(KEYBOARD_RIGHT) || key.isDown(KEYBOARD_DOWN) || key.isDown(KEYBOARD_d) || key.isDown(KEYBOARD_s) || key.controllerWantsRight(true))
{
game.press_right = true;
}
}
if (key.isDown(KEYBOARD_z) || key.isDown(KEYBOARD_SPACE) || key.isDown(KEYBOARD_v) || key.isDown(game.controllerButton_flip)) game.press_action = true;
//|| key.isDown(KEYBOARD_UP) || key.isDown(KEYBOARD_DOWN)) game.press_action = true; //on menus, up and down don't work as action
if (key.isDown(KEYBOARD_ENTER)) game.press_map = true;
Use dynamic credits lists for main menu credits screens (and add GitHub contributors) (#160) Also added GitHub contributors to the credits on the main menu (previously they were only present in the credits at the end of the game)
2020-02-12 05:45:58 +01:00
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
//In the menu system, all keypresses are single taps rather than holds. Therefore this test has to be done for all presses
if (!game.press_action && !game.press_left && !game.press_right) game.jumpheld = false;
if (!game.press_map) game.mapheld = false;
Use dynamic credits lists for main menu credits screens (and add GitHub contributors) (#160) Also added GitHub contributors to the credits on the main menu (previously they were only present in the credits at the end of the game)
2020-02-12 05:45:58 +01:00
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
if (!game.jumpheld && graphics.fademode==0)
{
if (game.press_action || game.press_left || game.press_right || game.press_map)
{
game.jumpheld = true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
if (key.isDown(27) && game.currentmenuname != Menu::youwannaquit && game.menustart)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
{
music.playef(11);
Make pressing Esc in ingame_titlemode go back to pause menu You shouldn't be able to bring up the youwannaquit menu while you're in-game, that should only be when you're actually not in game.
2020-06-23 02:29:30 +02:00
if (game.ingame_titlemode)
{
game.returntopausemenu();
}
else
{
game.createmenu(Menu::youwannaquit);
map.nexttowercolour();
}
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
}
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
if(game.menustart)
{
if (game.press_left)
{
game.currentmenuoption--;
}
else if (game.press_right)
{
game.currentmenuoption++;
}
}
if (game.currentmenuoption < 0) game.currentmenuoption = game.menuoptions.size()-1;
if (game.currentmenuoption >= (int) game.menuoptions.size() ) game.currentmenuoption = 0;
if (game.press_action)
{
if (!game.menustart)
{
game.menustart = true;
music.play(6);
music.playef(18);
game.screenshake = 10;
game.flashlight = 5;
}
else
{
menuactionpress();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
if ( game.currentmenuname == Menu::controller &&
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.currentmenuoption > 0 &&
Added ability to bind restart to a controller.
2020-08-09 00:41:59 +02:00
game.currentmenuoption < 5 &&
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
key.controllerButtonDown() )
{
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
updatebuttonmappings(game.currentmenuoption);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
if (graphics.fademode == 1)
Remove global args from scriptclass This commit removes all global args from the parameters of each function on the scriptclass object, and updates all places they are called accordingly. It also changes all instances of 'dwgfx' to 'graphics' in Script.cpp. Interestingly enough, it looks like editor.h depended on Script.h's class define of the musicclass. I've temporarily placed the class define in editor.h, but by the end of this patchset it'll be gone.
2020-03-31 21:38:52 +02:00
script.startgamemode(game.mainmenu);
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 gameinput(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//TODO mouse input
//game.mx = (mouseX / 2);
//game.my = (mouseY / 2);
if(!script.running)
{
game.press_left = false;
game.press_right = false;
game.press_action = false;
Remove outdated comments from Input.cpp There's a commented-out recording input option, which sounds interesting.
2020-04-03 02:59:08 +02:00
if (key.isDown(KEYBOARD_LEFT) || key.isDown(KEYBOARD_a) || key.controllerWantsLeft(false))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove outdated comments from Input.cpp There's a commented-out recording input option, which sounds interesting.
2020-04-03 02:59:08 +02:00
game.press_left = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Remove outdated comments from Input.cpp There's a commented-out recording input option, which sounds interesting.
2020-04-03 02:59:08 +02:00
if (key.isDown(KEYBOARD_RIGHT) || key.isDown(KEYBOARD_d) || key.controllerWantsRight(false))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove outdated comments from Input.cpp There's a commented-out recording input option, which sounds interesting.
2020-04-03 02:59:08 +02:00
game.press_right = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Remove outdated comments from Input.cpp There's a commented-out recording input option, which sounds interesting.
2020-04-03 02:59:08 +02:00
if (key.isDown(KEYBOARD_z) || key.isDown(KEYBOARD_SPACE) || key.isDown(KEYBOARD_v)
|| key.isDown(KEYBOARD_UP) || key.isDown(KEYBOARD_DOWN) || key.isDown(KEYBOARD_w) || key.isDown(KEYBOARD_s)|| key.isDown(game.controllerButton_flip))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove outdated comments from Input.cpp There's a commented-out recording input option, which sounds interesting.
2020-04-03 02:59:08 +02:00
game.press_action = true;
};
Hoist Enter check out of script.running clause This fixes the fact that an Enter release during a "- Press ACTION to advacne text -" prompt wouldn't be properly registered.
2020-09-06 13:49:53 +02:00
}
game.press_map = false;
if (key.isDown(KEYBOARD_ENTER) || key.isDown(SDLK_KP_ENTER) || key.isDown(game.controllerButton_map) )
{
game.press_map = true;
Remove outdated comments from Input.cpp There's a commented-out recording input option, which sounds interesting.
2020-04-03 02:59:08 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.advancetext)
{
if (game.pausescript)
{
game.press_action = false;
if (key.isDown(KEYBOARD_z) || key.isDown(KEYBOARD_SPACE) || key.isDown(KEYBOARD_v)
|| key.isDown(KEYBOARD_UP) || key.isDown(KEYBOARD_DOWN) || key.isDown(KEYBOARD_w) || key.isDown(KEYBOARD_s) || key.isDown(game.controllerButton_flip)) game.press_action = true;
}
if (game.press_action && !game.jumpheld)
{
if (game.pausescript)
{
game.pausescript = false;
game.hascontrol = true;
game.jumpheld = true;
}
else
{
Re-enable unbounded gamestate increment in glitchrunner mode This is the first part of what is necessary for credits warp to work. If the "- Press ACTION to advance text -" prompt is up, and you manage to keep it up, then you can indefinitely increment the gamestate by pressing ACTION. This is first used in credits warp to teleport to the start of Space Station 2 (by utilizing the Eurogame expo script, triggered by a gamestate), and then again later by using a teleporter that has a high gamestate number to increment to the [C[C[C[C[Captain!] cutscene.
2020-06-25 23:34:22 +02:00
if(game.glitchrunnermode || !game.glitchrunkludge) game.state++;
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
game.jumpheld = true;
game.glitchrunkludge=true;
//Bug fix! You should only be able to do this ONCE.
Re-enable unbounded gamestate increment in glitchrunner mode This is the first part of what is necessary for credits warp to work. If the "- Press ACTION to advance text -" prompt is up, and you manage to keep it up, then you can indefinitely increment the gamestate by pressing ACTION. This is first used in credits warp to teleport to the start of Space Station 2 (by utilizing the Eurogame expo script, triggered by a gamestate), and then again later by using a teleporter that has a high gamestate number to increment to the [C[C[C[C[Captain!] cutscene.
2020-06-25 23:34:22 +02:00
//...Unless you're in glitchrunner mode
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
Fix bringing up map menu during gamemode(teleporter) When gamemode(teleporter) gets run in a script, it brings up a read-only version of the teleporter screen, intended only for displaying rooms on the minimap. However, ever since 2.3 allowed bringing up the map screen during cutscenes (in order to prevent softlocks), bringing up the map screen during this mode would (1) do an unnecessary animation of suddenly switching back to the game and bringing up the menu screen again (even though the menu screen has already been brought up), and (2) would let you close the menu entirely and go back to GAMEMODE, thus unintentionally closing the teleporter screen and kind of ruining the cutscene. To fix this, when you bring up the map screen, it will instead instantly transition to the map screen. And when you bring it down, it will also instantly transition back to the teleporter screen. But that's not all. The previous behavior was actually kind of a nice failsafe, in that if you somehow got stuck in a state where a script ran gamemode(teleporter), but stopped running before it could take you out of that mode by running gamemode(game), then you could return to GAMEMODE yourself by bringing up the map screen and then bringing it back down. So I've made sure to keep that failsafe behavior, only as long as there isn't a script running.
2020-12-29 00:36:32 +01:00
if (!game.press_map
//Extra conditionals as a kludge fix so if you open the quit menu during
//the script command gamemode(teleporter) and close it with Esc, it won't
//immediately open again
//We really need a better input system soon...
&& !key.isDown(27)
&& !key.isDown(game.controllerButton_esc))
{
game.mapheld = false;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
if (game.intimetrial && graphics.fademode == 1 && game.quickrestartkludge)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//restart the time trial
game.quickrestartkludge = false;
Remove global args from scriptclass This commit removes all global args from the parameters of each function on the scriptclass object, and updates all places they are called accordingly. It also changes all instances of 'dwgfx' to 'graphics' in Script.cpp. Interestingly enough, it looks like editor.h depended on Script.h's class define of the musicclass. I've temporarily placed the class define in editor.h, but by the end of this patchset it'll be gone.
2020-03-31 21:38:52 +02:00
script.startgamemode(game.timetriallevel + 3);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.deathseq = -1;
game.completestop = false;
}
//Returning to editor mode must always be possible
Add option to allow custom levels when the editor is disabled
2020-02-10 03:21:19 +01:00
#if !defined(NO_CUSTOM_LEVELS)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if(map.custommode && !map.custommodeforreal){
Fix mixed indentation in Enter-handling code when playtesting It was indenting with 2 spaces instead of 4 spaces like the surrounding code.
2020-04-04 01:34:20 +02:00
if ((game.press_map || key.isDown(27)) && !game.mapheld){
//Return to level editor
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(game.activeactivity, obj.blocks) && game.press_map){
Don't duplicate activity zone handling code in playtesting This change makes it so that in in-editor playtesting, the code to handle pressing ENTER on activity zones is the same code to handle pressing ENTER on activity zones in custommodeforreal. This removes the need to copy-paste code and adapt it to in-editor playtesting. And thus, this fixes an editor artifact where you can press ENTER on activity zones while doing the death animation, even though you can't do that when you're playing custom levels normally.
2020-05-14 21:39:29 +02:00
//pass, let code block below handle it
Allow pressing Enter on teleporters during playtesting There's no reason you shouldn't be allowed to press Enter on teleporters during playtesting. Well, except that you can press Esc in the teleporter menu in order to go to the pause menu, which isn't intended in playtesting. But I can just add a check there so that pressing Esc closes the teleporter menu instead, it's fine.
2020-07-11 09:15:06 +02:00
}else if(game.activetele && game.readytotele > 20 && game.press_map){
//pass, let code block below handle it
Fix mixed indentation in Enter-handling code when playtesting It was indenting with 2 spaces instead of 4 spaces like the surrounding code.
2020-04-04 01:34:20 +02:00
}else{
Move returning to editor to end of frame This fixes horizontal and vertical warp backgrounds not resetting, and also a bunch of other 1-frame glitches, most noticeably cutscene bars and fadeouts. This adds a new variable shouldreturntoeditor to Game to signal whether or not it should return to editor at the end of the frame.
2020-05-09 21:52:58 +02:00
game.shouldreturntoeditor = true;
Don't duplicate activity zone handling code in playtesting This change makes it so that in in-editor playtesting, the code to handle pressing ENTER on activity zones is the same code to handle pressing ENTER on activity zones in custommodeforreal. This removes the need to copy-paste code and adapt it to in-editor playtesting. And thus, this fixes an editor artifact where you can press ENTER on activity zones while doing the death animation, even though you can't do that when you're playing custom levels normally.
2020-05-14 21:39:29 +02:00
game.mapheld = true;
Reset warp directions when exiting playtesting This fixes a bug where if warpdir() was used during in-editor playtesting, the changed warp direction would persist even when leaving playtesting. This would be very annoying to correct back every time you playtested and warpdir() was used, so I've added some kludge to store the actual warp direction of each room when entering playtesting, and then set the warp directions back when leaving playtesting.
2020-01-31 04:06:16 +01:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Entity type 0 is player controled
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
bool has_control = false;
bool enter_pressed = game.press_map && !game.mapheld;
bool enter_already_processed = false;
Refactor entities and linecrosskludge to not use the 'active' system This removes the variables obj.nentity and obj.nlinecrosskludge, as well as removing the 'active' attribute from the entity class object. Now every entity you access is guaranteed to be real and you don't have to check the 'active' variable. The biggest part of this is changing createentity() to modify a newly-created entity object and push it back instead of already modifying an indice in obj.entities. As well, removing an entity now uses the new obj.removeentity() function and removeentity_iter() macro.
2020-04-03 22:50:16 +02:00
for (size_t ie = 0; ie < obj.entities.size(); ++ie)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (obj.entities[ie].rule == 0)
{
if (game.hascontrol && game.deathseq == -1 && game.lifeseq <= 5)
{
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
has_control = true;
if (enter_pressed)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
game.mapheld = true;
Fix regression being able to activate activity zones during cutscenes Since you're now allowed to bring up the map screen during cutscenes, you've also been able to activate activity zones and teleporter prompts during cutscenes. This only really affects custom levels; nowhere in the main game can you overlap with an activity zone while in a cutscene. To fix this, I've just added a script.running check to Enter keybind processing.
2021-03-05 19:18:46 +01:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Fix regression being able to activate activity zones during cutscenes Since you're now allowed to bring up the map screen during cutscenes, you've also been able to activate activity zones and teleporter prompts during cutscenes. This only really affects custom levels; nowhere in the main game can you overlap with an activity zone while in a cutscene. To fix this, I've just added a script.running check to Enter keybind processing.
2021-03-05 19:18:46 +01:00
if (enter_pressed && !script.running)
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.activetele && game.readytotele > 20 && !game.intimetrial)
{
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
enter_already_processed = true;
Use SDL_fabsf where std::abs was previously used
2021-01-02 03:38:55 +01:00
if(int(SDL_fabsf(obj.entities[ie].vx))<=1 && int(obj.entities[ie].vy)==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//wait! space station 2 debug thingy
if (game.teleportscript != "")
{
//trace(game.recordstring);
//We're teleporting! Yey!
game.activetele = false;
game.hascontrol = false;
Remove outdated comments from Input.cpp There's a commented-out recording input option, which sounds interesting.
2020-04-03 02:59:08 +02:00
music.fadeout();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int player = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(player, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[player].colour = 102;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int teleporter = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(teleporter, obj.entities))
Guard all cases obj.getteleporter() is used unchecked obj.getteleporter() is able to return -1. If there's no check on it, it will end up indexing out-of-bounds, which is Undefined Behavior.
2020-06-13 04:31:08 +02:00
{
obj.entities[teleporter].tile = 6;
obj.entities[teleporter].colour = 102;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//which teleporter script do we use? it depends on the companion!
game.state = 4000;
game.statedelay = 0;
}
else if (game.companion == 0)
{
//Alright, normal teleporting
De-duplicate menu animation code when bringing up map screen When bringing up the map screen, the game does a small menu animation where the menu comes in from the bottom. The code to calculate the menu offset is copy-pasted everywhere, so I thought I'd de-duplicate it to make my life easier when working with it. I also included the game.gamestate assignment in the de-duplicated function, so it would be easier for a future bugfix. At the same time, I'm also removing all the BlitSurfaceStandard()s that copied menubuffer to backBuffer. The red flag is that this blit happened for every single entry point to MAPMODE and TELEPORTERMODE, except for the script command gamemode(teleporter). Pressing Enter to bring up the map screen, pressing Enter to quit the Super Gravitron, pressing Esc to bring up the pause screen, and pressing Enter to bring up the teleporter screen all do this blit, so if this blit was there to fix a bug, then there's a bug with using the script command gamemode(teleporter)... but, as far as I can tell, there isn't. That's because the blit basically does nothing. All the blit does is copy menubuffer onto backBuffer. Then the next thing that happens is that either maprender() or teleporterrender() will be called, and the first thing that those functions will always do is fill backBuffer with solid black, completely overriding the previous blit. So that's why removing this blit won't have any effect, and it can be safely removed for code clarity.
2020-12-28 23:23:35 +01:00
game.mapmenuchange(TELEPORTERMODE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.useteleporter = true;
Remove global args from Game I've decided to call dwgfx/game/map/obj/key/help/music the "global args". Because they're essentially global variables that are being passed around in args. This commit removes global args from all functions on the Game class, and deals with updating the callsites of said functions accordingly. It also renames all usages of 'dwgfx' in Game.cpp to 'graphics', since the global variable is called 'graphics' now. Interesting to note, I was removing the class defines from Game.h, but it turns out that Graphics.h depends on the mapclass and entityclass defines from Game.h. And also Graphics.h spelled mapclass wrong (it forgot the "class") so I just decided to use that existing line instead. This is only temporary and after all is said and done, at the end of this pull request those class defines will be gone.
2020-03-31 02:16:02 +02:00
game.initteleportermode();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
//We're teleporting! Yey!
game.activetele = false;
game.hascontrol = false;
Remove outdated comments from Input.cpp There's a commented-out recording input option, which sounds interesting.
2020-04-03 02:59:08 +02:00
music.fadeout();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int player = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(player, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[player].colour = 102;
}
Remove unused argument of entityclass::getcompanion() The argument provided to entityclass::getcompanion() does absolutely nothing. Remove it, and update all callers.
2020-04-02 00:32:21 +02:00
int companion = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if(INBOUNDS_VEC(companion, obj.entities)) obj.entities[companion].colour = 102;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int teleporter = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(teleporter, obj.entities))
Guard all cases obj.getteleporter() is used unchecked obj.getteleporter() is able to return -1. If there's no check on it, it will end up indexing out-of-bounds, which is Undefined Behavior.
2020-06-13 04:31:08 +02:00
{
obj.entities[teleporter].tile = 6;
obj.entities[teleporter].colour = 102;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//which teleporter script do we use? it depends on the companion!
game.state = 3000;
game.statedelay = 0;
}
}
}
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
else if (INBOUNDS_VEC(game.activeactivity, obj.blocks))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
enter_already_processed = true;
Use SDL_fabsf where std::abs was previously used
2021-01-02 03:38:55 +01:00
if((int(SDL_fabsf(obj.entities[ie].vx))<=1) && (int(obj.entities[ie].vy) == 0) )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
script.load(obj.blocks[game.activeactivity].script);
Fix entity and block indices after destroying them This patch restores some 2.2 behavior, fixing a regression caused by the refactor of properly using std::vectors. In 2.2, the game allocated 200 items in obj.entities, but used a system where each entity had an `active` attribute to signify if the entity actually existed or not. When dealing with entities, you would have to check this `active` flag, or else you'd be dealing with an entity that didn't actually exist. (By the way, what I'm saying applies to blocks and obj.blocks as well, except for some small differing details like the game allocating 500 block slots versus obj.entities's 200.) As a consequence, the game had to use a separate tracking variable, obj.nentity, because obj.entities.size() would just report 200, instead of the actual amount of entities. Needless to say, having to check for `active` and use `obj.nentity` is a bit error-prone, and it's messier than simply using the std::vector the way it was intended. Also, this resulted in a hard limit of 200 entities, which custom level makers ran into surprisingly quite often. 2.3 comes along, and removes the whole system. Now, std::vectors are properly being used, and obj.entities.size() reports the actual number of entities in the vector; you no longer have to check for `active` when dealing with entities of any sort. But there was one previous behavior of 2.2 that this system kind of forgets about - namely, the ability to have holes in between entities. You see, when an entity got disabled in 2.2 (which just meant turning its `active` off), the indices of all other entities stayed the same; the indice of the entity that got disabled stays there as a hole in the array. But when an entity gets removed in 2.3 (previous to this patch), the indices of every entity afterwards in the array get shifted down by one. std::vector isn't really meant to be able to contain holes. Do the indices of entities and blocks matter? Yes; they determine the order in which entities and blocks get evaluated (the highest indice gets evaluated first), and I had to fix some block evaluation order stuff in previous PRs. And in the case of entities, they matter hugely when using the recently-discovered Arbitrary Entity Manipulation glitch (where crewmate script commands are used on arbitrary entities by setting the `i` attribute of `scriptclass` and passing invalid crewmate identifiers to the commands). If you use Arbitrary Entity Manipulation after destroying some entities, there is a chance that your script won't work between 2.2 and 2.3. The indices also still determine the rendering order of entities (highest indice gets drawn first, which means lowest indice gets drawn in front of other entities). As an example: let's say we have the player at 0, a gravity line at 1, and a checkpoint at 2; then we destroy the gravity line and create a crewmate (let's do Violet). If we're able to have holes, then after removing the gravity line, none of the other indices shift. Then Violet will be created at indice 1, and will be drawn in front of the checkpoint. But if we can't have holes, then removing the gravity line results in the indice of the checkpoint shifting down to indice 1. Then Violet is created at indice 2, and gets drawn behind the checkpoint! This is a clear illustration of changing the behavior that existed in 2.2. However, I also don't want to go back to the `active` system of having to check an attribute before operating on an entity. So... what do we do to restore the holes? Well, we don't need to have an `active` attribute, or modify any existing code that operates on entities. Instead, we can just set the attributes of the entities so that they naturally get ignored by everything that comes into contact with it. For entities, we set their invis to true, and their size, type, and rule to -1 (the game never uses a size, type, or rule of -1 anywhere); for blocks, we set their type to -1, and their width and height to 0. obj.entities.size() will no longer necessarily equal the amount of entities in the room; rather, it will be the amount of entity SLOTS that have been allocated. But nothing that uses obj.entities.size() needs to actually know the amount of entities; it's mostly used for iterating over every entity in the vector. Excess entity slots get cleaned up upon every call of mapclass::gotoroom(), which will now deallocate entity slots starting from the end until it hits a player, at which point it will switch to disabling entity slots instead of removing them entirely. The entclass::clear() and blockclass::clear() functions have been restored because we need to call their initialization functions when reusing a block/entity slot; it's possible to create an entity with an invalid type number (it creates a glitchy Viridian), and without calling the initialization function again, it would simply not create anything. After this patch is applied, entity and block indices will be restored to how they behaved in 2.2.
2020-12-27 07:11:34 +01:00
obj.disableblock(game.activeactivity);
Fix undefined behavior when removing activity zones It turns out the game engaged in pseudo-UB when removing activity zones, which got turned into actual UB due to the previous commit. There were three places where this could happen: - Pressing ENTER on an activity zone in normal gameplay - Pressing ENTER on an activity zone in in-editor playtesting (because the code is duped here) - Pressing ESC and quitting to menu while standing inside an activity zone In all cases, game.activeactivity would still be pointing to a non-existent activity zone. This activity zone in the previous system would simply be a block with a false 'active', and in the system where C++ vectors are used properly, would index past the blocks array. In fact, it is a bug that when you press ENTER on an activity zone, the activity zone prompt suddenly turns to black, then immediately disappears. It was pointing to a block that had its clear() method called, which is why it was all black, and it was an inactive block! This commit makes it so pressing ENTER on an activity zone smoothly fades out the activity zone prompt instead of being sudden black.
2020-04-04 01:28:50 +02:00
game.activeactivity = -1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
if (game.press_left)
{
game.tapleft++;
}
else
{
if (game.tapleft <= 4 && game.tapleft > 0)
{
if (obj.entities[ie].vx < 0.0f)
{
obj.entities[ie].vx = 0.0f;
}
}
game.tapleft = 0;
}
if (game.press_right)
{
game.tapright++;
}
else
{
if (game.tapright <= 4 && game.tapright > 0)
{
if (obj.entities[ie].vx > 0.0f)
{
obj.entities[ie].vx = 0.0f;
}
}
game.tapright = 0;
}
if(game.press_left)
{
obj.entities[ie].ax = -3;
obj.entities[ie].dir = 0;
}
else if (game.press_right)
{
obj.entities[ie].ax = 3;
obj.entities[ie].dir = 1;
}
if (!game.press_action)
{
game.jumppressed = 0;
game.jumpheld = false;
}
if (game.press_action && !game.jumpheld)
{
game.jumppressed = 5;
game.jumpheld = true;
}
if (game.jumppressed > 0)
{
game.jumppressed--;
if (obj.entities[ie].onground>0 && game.gravitycontrol == 0)
{
game.gravitycontrol = 1;
obj.entities[ie].vy = -4;
obj.entities[ie].ay = -3;
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
music.playef(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.jumppressed = 0;
game.totalflips++;
}
if (obj.entities[ie].onroof>0 && game.gravitycontrol == 1)
{
game.gravitycontrol = 0;
obj.entities[ie].vy = 4;
obj.entities[ie].ay = 3;
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
music.playef(1);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.jumppressed = 0;
game.totalflips++;
}
}
}
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
if (!has_control)
{
//Simple detection of keypresses outside player control, will probably scrap this (expand on
//advance text function)
if (!game.press_action)
{
game.jumppressed = 0;
game.jumpheld = false;
}
if (game.press_action && !game.jumpheld)
{
game.jumppressed = 5;
game.jumpheld = true;
}
}
// Continuation of Enter processing. The rest of the if-tree runs only if
// enter_pressed && !enter_already_pressed
if (!enter_pressed || enter_already_processed)
{
// Do nothing
}
else if (game.swnmode == 1 && game.swngame == 1)
{
//quitting the super gravitron
game.mapheld = true;
//Quit menu, same conditions as in game menu
De-duplicate menu animation code when bringing up map screen When bringing up the map screen, the game does a small menu animation where the menu comes in from the bottom. The code to calculate the menu offset is copy-pasted everywhere, so I thought I'd de-duplicate it to make my life easier when working with it. I also included the game.gamestate assignment in the de-duplicated function, so it would be easier for a future bugfix. At the same time, I'm also removing all the BlitSurfaceStandard()s that copied menubuffer to backBuffer. The red flag is that this blit happened for every single entry point to MAPMODE and TELEPORTERMODE, except for the script command gamemode(teleporter). Pressing Enter to bring up the map screen, pressing Enter to quit the Super Gravitron, pressing Esc to bring up the pause screen, and pressing Enter to bring up the teleporter screen all do this blit, so if this blit was there to fix a bug, then there's a bug with using the script command gamemode(teleporter)... but, as far as I can tell, there isn't. That's because the blit basically does nothing. All the blit does is copy menubuffer onto backBuffer. Then the next thing that happens is that either maprender() or teleporterrender() will be called, and the first thing that those functions will always do is fill backBuffer with solid black, completely overriding the previous blit. So that's why removing this blit won't have any effect, and it can be safely removed for code clarity.
2020-12-28 23:23:35 +01:00
game.mapmenuchange(MAPMODE);
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
game.gamesaved = false;
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
game.gamesavefailed = false;
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
game.menupage = 20; // The Map Page
}
Remove fademode conditional from map screen There's not really any good reason to prevent this action during a fade animation. That just makes the fade timer one more potential contributor to a softlock. I'm leaving the fademode conditional on the Time Trial quick restart, though - removing it would mean being able to quick restart during a fade-in, and thus being able to spam Enter over and over to keep re-starting the fade animation, which looks goofy.
2020-09-06 13:28:18 +02:00
else if (game.intimetrial && graphics.fademode == 0)
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
{
//Quick restart of time trial
graphics.fademode = 2;
game.completestop = true;
music.fadeout();
game.quickrestartkludge = true;
}
Remove fademode conditional from map screen There's not really any good reason to prevent this action during a fade animation. That just makes the fade timer one more potential contributor to a softlock. I'm leaving the fademode conditional on the Time Trial quick restart, though - removing it would mean being able to quick restart during a fade-in, and thus being able to spam Enter over and over to keep re-starting the fade animation, which looks goofy.
2020-09-06 13:28:18 +02:00
else if (game.intimetrial)
{
//Do nothing if we're in a Time Trial but a fade animation is playing
}
else
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
{
//Normal map screen, do transition later
De-duplicate menu animation code when bringing up map screen When bringing up the map screen, the game does a small menu animation where the menu comes in from the bottom. The code to calculate the menu offset is copy-pasted everywhere, so I thought I'd de-duplicate it to make my life easier when working with it. I also included the game.gamestate assignment in the de-duplicated function, so it would be easier for a future bugfix. At the same time, I'm also removing all the BlitSurfaceStandard()s that copied menubuffer to backBuffer. The red flag is that this blit happened for every single entry point to MAPMODE and TELEPORTERMODE, except for the script command gamemode(teleporter). Pressing Enter to bring up the map screen, pressing Enter to quit the Super Gravitron, pressing Esc to bring up the pause screen, and pressing Enter to bring up the teleporter screen all do this blit, so if this blit was there to fix a bug, then there's a bug with using the script command gamemode(teleporter)... but, as far as I can tell, there isn't. That's because the blit basically does nothing. All the blit does is copy menubuffer onto backBuffer. Then the next thing that happens is that either maprender() or teleporterrender() will be called, and the first thing that those functions will always do is fill backBuffer with solid black, completely overriding the previous blit. So that's why removing this blit won't have any effect, and it can be safely removed for code clarity.
2020-12-28 23:23:35 +01:00
game.mapmenuchange(MAPMODE);
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
map.cursordelay = 0;
map.cursorstate = 0;
game.gamesaved = false;
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
game.gamesavefailed = false;
Restrict the ENTER menu to saving while in a cutscene PR #468 made it so you can use the menus while in a cutscene, in order to counteract softlocks. However, this has resulted in more unintentional behavior: - `gamemode(teleporter)` breaks when opening the ENTER menu (Misa mentioned this) - The player can now interrupt shakes and walks, and have their timers run out before resuming the cutscene - After completing the game, the player can warp to the ship while a dialogue is active, and prevent themselves from advancing text (plus it's always rude to just teleport away while someone's talking) - The player can peek at the map before hidecoordinates is run, and can also peek at what the game does with missing/rescued crewmates during cutscenes This commit fixes the latter two issues. While a script is running, only the SAVE tab is now available. Therefore the player can still get themselves out of softlocks as intended, but they do things like looking at the map or teleporting away during a cutscene.
2020-11-16 00:32:44 +01:00
if (script.running)
{
game.menupage = 3; // Only allow saving
}
else
{
game.menupage = 0; // The Map Page
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
Fix bringing up map menu during gamemode(teleporter) When gamemode(teleporter) gets run in a script, it brings up a read-only version of the teleporter screen, intended only for displaying rooms on the minimap. However, ever since 2.3 allowed bringing up the map screen during cutscenes (in order to prevent softlocks), bringing up the map screen during this mode would (1) do an unnecessary animation of suddenly switching back to the game and bringing up the menu screen again (even though the menu screen has already been brought up), and (2) would let you close the menu entirely and go back to GAMEMODE, thus unintentionally closing the teleporter screen and kind of ruining the cutscene. To fix this, when you bring up the map screen, it will instead instantly transition to the map screen. And when you bring it down, it will also instantly transition back to the teleporter screen. But that's not all. The previous behavior was actually kind of a nice failsafe, in that if you somehow got stuck in a state where a script ran gamemode(teleporter), but stopped running before it could take you out of that mode by running gamemode(game), then you could return to GAMEMODE yourself by bringing up the map screen and then bringing it back down. So I've made sure to keep that failsafe behavior, only as long as there isn't a script running.
2020-12-29 00:36:32 +01:00
if (!game.mapheld
&& (key.isDown(27) || key.isDown(game.controllerButton_esc))
&& (!map.custommode || map.custommodeforreal))
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
{
game.mapheld = true;
//Quit menu, same conditions as in game menu
De-duplicate menu animation code when bringing up map screen When bringing up the map screen, the game does a small menu animation where the menu comes in from the bottom. The code to calculate the menu offset is copy-pasted everywhere, so I thought I'd de-duplicate it to make my life easier when working with it. I also included the game.gamestate assignment in the de-duplicated function, so it would be easier for a future bugfix. At the same time, I'm also removing all the BlitSurfaceStandard()s that copied menubuffer to backBuffer. The red flag is that this blit happened for every single entry point to MAPMODE and TELEPORTERMODE, except for the script command gamemode(teleporter). Pressing Enter to bring up the map screen, pressing Enter to quit the Super Gravitron, pressing Esc to bring up the pause screen, and pressing Enter to bring up the teleporter screen all do this blit, so if this blit was there to fix a bug, then there's a bug with using the script command gamemode(teleporter)... but, as far as I can tell, there isn't. That's because the blit basically does nothing. All the blit does is copy menubuffer onto backBuffer. Then the next thing that happens is that either maprender() or teleporterrender() will be called, and the first thing that those functions will always do is fill backBuffer with solid black, completely overriding the previous blit. So that's why removing this blit won't have any effect, and it can be safely removed for code clarity.
2020-12-28 23:23:35 +01:00
game.mapmenuchange(MAPMODE);
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
game.gamesaved = false;
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
game.gamesavefailed = false;
Hoist Enter/Esc presses out of player entity for-loop The hooks to bring up the map screen, pause screen, quit from Super Gravitron, restart Time Trial, and commit suicide have now been hoisted out of the for-loop that checked for a player entity. None of these actions require a player entity, and there's no good reason to take away your control from any of these actions, especially being able to quit to the menu. The only actions inside the for-loop now are activating a terminal and activating a teleporter, both of which require a player entity to be standing in front of a terminal or teleporter, and both of which have good reasons to be temporarily disabled.
2020-09-06 13:28:09 +02:00
game.menupage = 30; // Pause screen
}
if (game.deathseq == -1 && (key.isDown(SDLK_r) || key.isDown(game.controllerButton_restart)) && !game.nodeathmode)// && map.custommode) //Have fun glitchrunners!
{
game.deathseq = 30;
}
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
static void mapmenuactionpress(void);
Move mapinput() ACTION press handling to separate function It's a bit too much to consolidate all the ACTION press handling into one function, especially given the increasing amount of indentation levels.
2020-06-23 00:30:10 +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 mapinput(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//TODO Mouse Input!
//game.mx = (mouseX / 2);
//game.my = (mouseY / 2);
game.press_left = false;
game.press_right = false;
game.press_action = false;
game.press_map = false;
Restore janky gamestate-based quit-to-title system in glitchrunnermode This was fixed in 2.3 because one of the side effects of this janky system was being able to accidentally immediately quit to the title if the screen was black during a cutscene, which is something very likely to happen to casual players. Anyway, credits warp uses this gamestate-based system because it utilizes quitting to the title screen doing gamestate 80. From there, you increment the gamestate to gamestate 94 to use the Space Station 2 expo script.
2020-06-25 23:41:44 +02:00
if (game.glitchrunnermode && graphics.fademode == 1 && graphics.menuoffset == 0)
{
// Deliberate re-addition of the glitchy gamestate-based fadeout!
// First of all, detecting a black screen means if the glitchy fadeout
// gets interrupted but you're still on a black screen, opening a menu
// immediately quits you to the title. This has the side effect that if
// you accidentally press Esc during a cutscene when it's black, you'll
// immediately be quit and lose all your progress, but that's fair in
// glitchrunner mode.
// Also have to check graphics.menuoffset so this doesn't run every frame
Remove half-second delay when exiting to menu in glitchrunner mode The half-second delay comes from the fact that the game uses graphics.resumegamemode to go back to GAMEMODE. This system waits for graphics.menuoffset to reach a certain threshold before actually going back (this is the animation of the map screen being brought down). To speed it up, I'll just set graphics.menuoffset directly. I could've directly set game.gamestate to GAMEMODE, but I wanted to be safe and use the existing system instead.
2020-08-03 06:43:55 +02:00
// Have to close the menu in order to run gamestates
Restore janky gamestate-based quit-to-title system in glitchrunnermode This was fixed in 2.3 because one of the side effects of this janky system was being able to accidentally immediately quit to the title if the screen was black during a cutscene, which is something very likely to happen to casual players. Anyway, credits warp uses this gamestate-based system because it utilizes quitting to the title screen doing gamestate 80. From there, you increment the gamestate to gamestate 94 to use the Space Station 2 expo script.
2020-06-25 23:41:44 +02:00
graphics.resumegamemode = true;
Remove half-second delay when exiting to menu in glitchrunner mode The half-second delay comes from the fact that the game uses graphics.resumegamemode to go back to GAMEMODE. This system waits for graphics.menuoffset to reach a certain threshold before actually going back (this is the animation of the map screen being brought down). To speed it up, I'll just set graphics.menuoffset directly. I could've directly set game.gamestate to GAMEMODE, but I wanted to be safe and use the existing system instead.
2020-08-03 06:43:55 +02:00
// Remove half-second delay
graphics.menuoffset = 250;
Restore janky gamestate-based quit-to-title system in glitchrunnermode This was fixed in 2.3 because one of the side effects of this janky system was being able to accidentally immediately quit to the title if the screen was black during a cutscene, which is something very likely to happen to casual players. Anyway, credits warp uses this gamestate-based system because it utilizes quitting to the title screen doing gamestate 80. From there, you increment the gamestate to gamestate 94 to use the Space Station 2 expo script.
2020-06-25 23:41:44 +02:00
// Technically this was in <=2.2 as well
obj.removeallblocks();
if (game.menupage >= 20 && game.menupage <= 21)
{
game.state = 96;
game.statedelay = 0;
}
else
{
// Produces more glitchiness! Necessary for credits warp to work.
Fix aggressive glitchrunner hardreset causing issues quitting to menu This fixes the bug where in glitchrunner mode, quitting to the menu would always put you back at the play menu on the first option, instead of the menu you entered the game from. The problem is the script.hardreset() that gets called before the game actually quits to the menu, so when Game::quittomenu() gets called to quit to the menu, all the variables that keep track of whether you're in a certain gamemode, such as game.insecretlab and map.custommode, all get prematurely reset before that function can read them and put you back to the correct menu. The solution here is to simply reset only what's needed when quitting to the menu. Specifically, in order for credits warp to work, script.running needs to be set to false and all the text boxes need to be removed. Text boxes need to be gone so the "- Press ACTION to advance text -" prompt will stay up without a text box, enabling the player to increment the gamestate at will by pressing ACTION, and the script needs to stop running so further text boxes don't spawn in. Fixes #389.
2020-08-14 04:26:52 +02:00
script.running = false;
graphics.textbox.clear();
Restore janky gamestate-based quit-to-title system in glitchrunnermode This was fixed in 2.3 because one of the side effects of this janky system was being able to accidentally immediately quit to the title if the screen was black during a cutscene, which is something very likely to happen to casual players. Anyway, credits warp uses this gamestate-based system because it utilizes quitting to the title screen doing gamestate 80. From there, you increment the gamestate to gamestate 94 to use the Space Station 2 expo script.
2020-06-25 23:41:44 +02:00
game.state = 80;
game.statedelay = 0;
}
}
if (game.fadetomenu && !game.glitchrunnermode)
Move fading to menu to separate variables Alright, so what I've done here is made exiting to the menu entirely separate from Terry's State Machine, and thus it can now take place entirely within MAPMODE instead of having to go back to GAMEMODE. Also, it's faster by 15 frames since we don't need to wait for the map screen to go back down.
2020-05-08 00:23:55 +02:00
{
if (game.fadetomenudelay > 0)
{
game.fadetomenudelay--;
}
else
{
game.quittomenu();
Clean up all exit paths to the menu to use common code There are multiple different exit paths to the main menu. In 2.2, they all had a bunch of copy-pasted code. In 2.3 currently, most of them use game.quittomenu(), but there are some stragglers that still use hand-copied code. This is a bit of a problem, because all exit paths should consistently have FILESYSTEM_unmountassets(), as part of the 2.3 feature of per-level custom assets. Furthermore, most (but not all) of the paths call script.hardreset() too, and some of the stragglers don't. So there could be something persisting through to the title screen (like a really long flash/shake timer) that could only persist if exiting to the title screen through those paths. But, actually, it seems like there's a good reason for some of those to not call script.hardreset() - namely, dying or completing No Death Mode and completing a Time Trial presents some information onscreen that would get reset by script.hardreset(), so I'll fix that in a later commit. So what I've done for this commit is found every exit path that didn't already use game.quittomenu(), and made them use game.quittomenu(). As well, some of them had special handling that existed on top of them already having a corresponding entry in game.quittomenu() (but the path would take the special handling because it never did game.quittomenu()), so I removed that special handling as well (e.g. exiting from a custom level used returntomenu(Menu::levellist) when quittomenu() already had that same returntomenu()). The menu that exiting from the level editor returns to is now handled in game.quittomenu() as well, where the map.custommode branch now also checks for map.custommodeforreal. Unfortunately, it seems like entering the level editor doesn't properly initialize map.custommode, so entering the level editor now initializes map.custommode, too. I've also taken the music.play(6) out of game.quittomenu(), because not all exit paths immediately play Presenting VVVVVV, so all exit paths that DO immediately play Presenting VVVVVV now have music.play(6) special-cased for them, which is fine enough for me. Here is the list of all exit paths to the menu: - Exiting through the pause menu (without glitchrunner mode) - Exiting through the pause menu (with glitchrunner mode) - Completing a custom level - Completing a Time Trial - Dying in No Death Mode - Completing No Death Mode - Completing an Intermission replay - Exiting from the level editor - Completing the main game
2021-01-07 23:20:37 +01:00
music.play(6); //should be after game.quittomenu()
Move fading to menu to separate variables Alright, so what I've done here is made exiting to the menu entirely separate from Terry's State Machine, and thus it can now take place entirely within MAPMODE instead of having to go back to GAMEMODE. Also, it's faster by 15 frames since we don't need to wait for the map screen to go back down.
2020-05-08 00:23:55 +02:00
game.fadetomenu = false;
}
}
Restore janky gamestate-based quit-to-title system in glitchrunnermode This was fixed in 2.3 because one of the side effects of this janky system was being able to accidentally immediately quit to the title if the screen was black during a cutscene, which is something very likely to happen to casual players. Anyway, credits warp uses this gamestate-based system because it utilizes quitting to the title screen doing gamestate 80. From there, you increment the gamestate to gamestate 94 to use the Space Station 2 expo script.
2020-06-25 23:41:44 +02:00
if (game.fadetolab && !game.glitchrunnermode)
Move returning to lab to separate variables Again, what I've done here is removed the over-reliance on Terry's State Machine to return to the lab, and just moved it into separate variables instead. This means that returning to the lab is ALMOST entirely self-contained in MAPMODE, except there's a quick jaunt over to GAMEMODE to run a script because you can only run scripts in GAMEMODE.
2020-05-08 00:30:26 +02:00
{
if (game.fadetolabdelay > 0)
{
game.fadetolabdelay--;
}
else
{
game.returntolab();
game.fadetolab = false;
}
}
Restore janky gamestate-based quit-to-title system in glitchrunnermode This was fixed in 2.3 because one of the side effects of this janky system was being able to accidentally immediately quit to the title if the screen was black during a cutscene, which is something very likely to happen to casual players. Anyway, credits warp uses this gamestate-based system because it utilizes quitting to the title screen doing gamestate 80. From there, you increment the gamestate to gamestate 94 to use the Space Station 2 expo script.
2020-06-25 23:41:44 +02:00
if(graphics.menuoffset==0
Fix ACTION press processing on same frame as fade ticks to 0 Here's what causes #401: After the fade to menu delay ticks down to 0, the game calls game.quittomenu(), but the rest of mapinput() still executes. This means that the block that detects your ACTION press gets executed, because there's a check that fadetomenudelay is less than or equal to 0, and, well, it is. So if you've pressed ACTION on the exact frame that it counts down to 0, then the game detects your ACTION press, then processes it accordingly, and then sets the fadetomenudelay, which means it'll get reactivated the next time you open the map screen. But at this point, you get sent to TITLEMODE, because game.quittomenu() set game.gamestate accordingly. (This is why resetting game.fadetomenu or game.fadetomenudelay in game.quittomenu() or script.hardreset() won't fix this bug.) The solution here is to add a game.fadetomenu check to the ACTION press processing. Same-frame state transition logic is hard... actually, any sort of thing where two things happen on the same frame is really annoying. This also applies to fadetolab and fadetolabdelay, too. Fixes #401.
2020-11-06 10:03:47 +01:00
&& ((!game.glitchrunnermode && !game.fadetomenu && game.fadetomenudelay <= 0 && !game.fadetolab && game.fadetolabdelay <= 0)
Fix softlock if exiting Super Grav and bringing up map in glitchrunner The game would softlock if you brought up the map screen or quit screen after exiting the Super Gravitron to the Secret Lab. This softlock would only happen if you were in glitchrunner mode. This is because glitchrunner mode set game.fadetolabdelay when it shouldn't have, and also checked game.fadetolabdelay when it shouldn't have. So I made it so that the game will only set game.fadetolabdelay when not in glitchrunner mode (I already had a check for game.fadetomenudelay, too!) and the game will only check for game.fadetomenudelay and game.fadetolabdelay when not in glitchrunner mode, as well. I originally made the game check game.fadetomenudelay and game.fadetolabdelay to prevent being able to re-press ACTION to re-start the fadeout if the game was already fading out. And I made sure that this wasn't broken, both in glitchrunner mode and normal mode.
2020-07-17 00:11:54 +02:00
|| graphics.fademode == 0))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix up/down being reversed in in-game menu in Flip Mode This bug is technically NOT a regression - the code responsible for it has been around since the source release. However, it hasn't been a problem until Graphic Options and Game Options were added to the pause screen. Since then, if you opened the pause menu in Flip Mode, pressing up would move to the menu option below, and pressing down would move to the menu option above. Notably, left and right still remain the same. This is because the map screen input code assumes that the menu options will be flipped around - however, this has never been the case. What happens instead is that the menu options get flipped around time when in Flip Mode - flipping what's already flipped - so it ends up the same again. (Incidentally enough, the up/down reversing code is present on the title screen, and is correct - if you happen to set graphics.flipmode to true on the title screen, the title screen doesn't negate the flipped menu options, so pressing up SHOULD be treated like pressing down, and vice versa. However, in 2.3, it's not really possible to set graphics.flipmode to true on the title screen without using GDB or modifying the game. In 2.2 and previous, you can just complete the game in Flip Mode, and the variable won't be reset; 2.3 cleaned up all exit paths to the menu to make sure everything got reset.) This isn't a problem when there's only two options, but since 2.3 adds two more options to the pause screen, it's pretty noticeable. Anyway, this is fixed by simply removing the branch of the graphics.flipmode if-else in mapinput(). The 'else' branch is now the code that gets executed unconditionally. Don't get confused by the diff; I decided to unindent in the same commit because it's not that many lines of code.
2021-03-06 04:34:15 +01:00
if (key.isDown(KEYBOARD_LEFT) || key.isDown(KEYBOARD_UP) || key.isDown(KEYBOARD_a) || key.isDown(KEYBOARD_w)|| key.controllerWantsLeft(true))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix up/down being reversed in in-game menu in Flip Mode This bug is technically NOT a regression - the code responsible for it has been around since the source release. However, it hasn't been a problem until Graphic Options and Game Options were added to the pause screen. Since then, if you opened the pause menu in Flip Mode, pressing up would move to the menu option below, and pressing down would move to the menu option above. Notably, left and right still remain the same. This is because the map screen input code assumes that the menu options will be flipped around - however, this has never been the case. What happens instead is that the menu options get flipped around time when in Flip Mode - flipping what's already flipped - so it ends up the same again. (Incidentally enough, the up/down reversing code is present on the title screen, and is correct - if you happen to set graphics.flipmode to true on the title screen, the title screen doesn't negate the flipped menu options, so pressing up SHOULD be treated like pressing down, and vice versa. However, in 2.3, it's not really possible to set graphics.flipmode to true on the title screen without using GDB or modifying the game. In 2.2 and previous, you can just complete the game in Flip Mode, and the variable won't be reset; 2.3 cleaned up all exit paths to the menu to make sure everything got reset.) This isn't a problem when there's only two options, but since 2.3 adds two more options to the pause screen, it's pretty noticeable. Anyway, this is fixed by simply removing the branch of the graphics.flipmode if-else in mapinput(). The 'else' branch is now the code that gets executed unconditionally. Don't get confused by the diff; I decided to unindent in the same commit because it's not that many lines of code.
2021-03-06 04:34:15 +01:00
game.press_left = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Fix up/down being reversed in in-game menu in Flip Mode This bug is technically NOT a regression - the code responsible for it has been around since the source release. However, it hasn't been a problem until Graphic Options and Game Options were added to the pause screen. Since then, if you opened the pause menu in Flip Mode, pressing up would move to the menu option below, and pressing down would move to the menu option above. Notably, left and right still remain the same. This is because the map screen input code assumes that the menu options will be flipped around - however, this has never been the case. What happens instead is that the menu options get flipped around time when in Flip Mode - flipping what's already flipped - so it ends up the same again. (Incidentally enough, the up/down reversing code is present on the title screen, and is correct - if you happen to set graphics.flipmode to true on the title screen, the title screen doesn't negate the flipped menu options, so pressing up SHOULD be treated like pressing down, and vice versa. However, in 2.3, it's not really possible to set graphics.flipmode to true on the title screen without using GDB or modifying the game. In 2.2 and previous, you can just complete the game in Flip Mode, and the variable won't be reset; 2.3 cleaned up all exit paths to the menu to make sure everything got reset.) This isn't a problem when there's only two options, but since 2.3 adds two more options to the pause screen, it's pretty noticeable. Anyway, this is fixed by simply removing the branch of the graphics.flipmode if-else in mapinput(). The 'else' branch is now the code that gets executed unconditionally. Don't get confused by the diff; I decided to unindent in the same commit because it's not that many lines of code.
2021-03-06 04:34:15 +01:00
if (key.isDown(KEYBOARD_RIGHT) || key.isDown(KEYBOARD_DOWN) || key.isDown(KEYBOARD_d) || key.isDown(KEYBOARD_s)|| key.controllerWantsRight(true))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix up/down being reversed in in-game menu in Flip Mode This bug is technically NOT a regression - the code responsible for it has been around since the source release. However, it hasn't been a problem until Graphic Options and Game Options were added to the pause screen. Since then, if you opened the pause menu in Flip Mode, pressing up would move to the menu option below, and pressing down would move to the menu option above. Notably, left and right still remain the same. This is because the map screen input code assumes that the menu options will be flipped around - however, this has never been the case. What happens instead is that the menu options get flipped around time when in Flip Mode - flipping what's already flipped - so it ends up the same again. (Incidentally enough, the up/down reversing code is present on the title screen, and is correct - if you happen to set graphics.flipmode to true on the title screen, the title screen doesn't negate the flipped menu options, so pressing up SHOULD be treated like pressing down, and vice versa. However, in 2.3, it's not really possible to set graphics.flipmode to true on the title screen without using GDB or modifying the game. In 2.2 and previous, you can just complete the game in Flip Mode, and the variable won't be reset; 2.3 cleaned up all exit paths to the menu to make sure everything got reset.) This isn't a problem when there's only two options, but since 2.3 adds two more options to the pause screen, it's pretty noticeable. Anyway, this is fixed by simply removing the branch of the graphics.flipmode if-else in mapinput(). The 'else' branch is now the code that gets executed unconditionally. Don't get confused by the diff; I decided to unindent in the same commit because it's not that many lines of code.
2021-03-06 04:34:15 +01:00
game.press_right = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if (key.isDown(KEYBOARD_z) || key.isDown(KEYBOARD_SPACE) || key.isDown(KEYBOARD_v) || key.isDown(game.controllerButton_flip))
{
game.press_action = true;
}
Allow pressing Esc to close Esc menu Another thing that's annoyed me a lot is being unable to simply press Esc to close the pause menu. You'd have to hover over the "return to game" or "keep playing" option. This would be even more annoying with more options on the menu, so allowing to press Esc is a nice quality-of-life thing.
2020-06-23 06:36:50 +02:00
if (game.menupage < 12 || (game.menupage >= 30 && game.menupage <= 33))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (key.isDown(KEYBOARD_ENTER) || key.isDown(game.controllerButton_map) ) game.press_map = true;
Allow pressing Esc to close Esc menu Another thing that's annoyed me a lot is being unable to simply press Esc to close the pause menu. You'd have to hover over the "return to game" or "keep playing" option. This would be even more annoying with more options on the menu, so allowing to press Esc is a nice quality-of-life thing.
2020-06-23 06:36:50 +02:00
if (key.isDown(27) && !game.mapheld)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
game.mapheld = true;
Allow pressing Esc to go back to pause menu from quit prompt Allowing for more actions makes things feel smoother.
2020-06-23 06:20:05 +02:00
if (game.menupage < 9)
{
game.menupage = 30;
}
Allow pressing Esc to close Esc menu Another thing that's annoyed me a lot is being unable to simply press Esc to close the pause menu. You'd have to hover over the "return to game" or "keep playing" option. This would be even more annoying with more options on the menu, so allowing to press Esc is a nice quality-of-life thing.
2020-06-23 06:36:50 +02:00
else if (game.menupage < 12)
Allow pressing Esc to go back to pause menu from quit prompt Allowing for more actions makes things feel smoother.
2020-06-23 06:20:05 +02:00
{
game.menupage = 31;
}
Allow pressing Esc to close Esc menu Another thing that's annoyed me a lot is being unable to simply press Esc to close the pause menu. You'd have to hover over the "return to game" or "keep playing" option. This would be even more annoying with more options on the menu, so allowing to press Esc is a nice quality-of-life thing.
2020-06-23 06:36:50 +02:00
else
{
graphics.resumegamemode = true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else
{
if (key.isDown(KEYBOARD_ENTER) || key.isDown(27)|| key.isDown(game.controllerButton_map) ) game.press_map = true;
}
//In the menu system, all keypresses are single taps rather than holds. Therefore this test has to be done for all presses
if (!game.press_action && !game.press_left && !game.press_right)
{
game.jumpheld = false;
}
if (!game.press_map && !key.isDown(27))
{
game.mapheld = false;
}
}
else
{
game.mapheld = true;
game.jumpheld = true;
}
if (!game.mapheld)
{
if(game.press_map && game.menupage < 10)
{
//Normal map screen, do transition later
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
graphics.resumegamemode = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
if (!game.jumpheld)
{
if (game.press_action || game.press_left || game.press_right || game.press_map)
{
game.jumpheld = true;
}
Restrict the ENTER menu to saving while in a cutscene PR #468 made it so you can use the menus while in a cutscene, in order to counteract softlocks. However, this has resulted in more unintentional behavior: - `gamemode(teleporter)` breaks when opening the ENTER menu (Misa mentioned this) - The player can now interrupt shakes and walks, and have their timers run out before resuming the cutscene - After completing the game, the player can warp to the ship while a dialogue is active, and prevent themselves from advancing text (plus it's always rude to just teleport away while someone's talking) - The player can peek at the map before hidecoordinates is run, and can also peek at what the game does with missing/rescued crewmates during cutscenes This commit fixes the latter two issues. While a script is running, only the SAVE tab is now available. Therefore the player can still get themselves out of softlocks as intended, but they do things like looking at the map or teleporting away during a cutscene.
2020-11-16 00:32:44 +01:00
if (script.running && game.menupage == 3)
{
// Force the player to stay in the SAVE tab while in a cutscene
}
else if (game.press_left)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
game.menupage--;
}
else if (game.press_right)
{
game.menupage++;
}
Pull the game.press_action conditional out of all the if-statements No need to repeat yourself if you can just surround the whole thing in an 'if (game.press_action)' block, which is much easier.
2020-06-23 00:32:21 +02:00
if (game.press_action)
{
mapmenuactionpress();
}
Move mapinput() ACTION press handling to separate function It's a bit too much to consolidate all the ACTION press handling into one function, especially given the increasing amount of indentation levels.
2020-06-23 00:30:10 +02:00
if (game.menupage < 0) game.menupage = 3;
if (game.menupage > 3 && game.menupage < 9) game.menupage = 0;
if (game.menupage == 9) game.menupage = 11;
if (game.menupage == 12) game.menupage = 10;
if (game.menupage == 19) game.menupage = 21;
if (game.menupage == 22) game.menupage = 20;
if (game.menupage == 29) game.menupage = 33;
if (game.menupage == 34) game.menupage = 30;
}
}
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
static void mapmenuactionpress(void)
Move mapinput() ACTION press handling to separate function It's a bit too much to consolidate all the ACTION press handling into one function, especially given the increasing amount of indentation levels.
2020-06-23 00:30:10 +02:00
{
Use case-switch in mapmenuactionpress() This prevents from having to repeat 'if (game.menupage == ...)' everywhere, which makes for more concise code. I know you're technically supposed to indent the cases surrounded by if-guards, but I don't think indenting them here would help anything. I'd only indent it if the 'if' had an 'else', for example. But if it surrounds the whole case, then there's no need for indentation.
2020-06-23 00:35:26 +02:00
switch (game.menupage)
{
case 1:
Use game.inspecial() in mapmenuactionpress() Apart from covering more cases with the SHIP option, it also makes the if-guard for case 3 much less noisy on the eyes.
2020-06-23 00:37:19 +02:00
if (obj.flags[67] && !game.inspecial() && !map.custommode)
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
{
//Warp back to the ship
graphics.resumegamemode = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
game.teleport_to_x = 2;
game.teleport_to_y = 11;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
//trace(game.recordstring);
//We're teleporting! Yey!
game.activetele = false;
game.hascontrol = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
{
obj.entities[i].colour = 102;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
//which teleporter script do we use? it depends on the companion!
game.state = 4000;
game.statedelay = 0;
}
Use case-switch in mapmenuactionpress() This prevents from having to repeat 'if (game.menupage == ...)' everywhere, which makes for more concise code. I know you're technically supposed to indent the cases surrounded by if-guards, but I don't think indenting them here would help anything. I'd only indent it if the 'if' had an 'else', for example. But if it surrounds the whole case, then there's no need for indentation.
2020-06-23 00:35:26 +02:00
break;
case 3:
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
if (!game.gamesaved && !game.gamesavefailed && !game.inspecial())
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
{
game.flashlight = 5;
game.screenshake = 10;
music.playef(18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
game.savetime = game.timestring();
game.savearea = map.currentarea(map.area(game.roomx, game.roomy));
game.savetrinkets = game.trinkets();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
if (game.roomx >= 102 && game.roomx <= 104 && game.roomy >= 110 && game.roomy <= 111) game.savearea = "The Ship";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
bool success;
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
#if !defined(NO_CUSTOM_LEVELS)
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
if(map.custommodeforreal)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
success = game.customsavequick(ed.ListOfMetaData[game.playcustomlevel].filename);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
else
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
success = game.savequick();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
game.gamesaved = success;
game.gamesavefailed = !success;
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
}
Use case-switch in mapmenuactionpress() This prevents from having to repeat 'if (game.menupage == ...)' everywhere, which makes for more concise code. I know you're technically supposed to indent the cases surrounded by if-guards, but I don't think indenting them here would help anything. I'd only indent it if the 'if' had an 'else', for example. But if it surrounds the whole case, then there's no need for indentation.
2020-06-23 00:35:26 +02:00
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Use case-switch in mapmenuactionpress() This prevents from having to repeat 'if (game.menupage == ...)' everywhere, which makes for more concise code. I know you're technically supposed to indent the cases surrounded by if-guards, but I don't think indenting them here would help anything. I'd only indent it if the 'if' had an 'else', for example. But if it surrounds the whole case, then there's no need for indentation.
2020-06-23 00:35:26 +02:00
case 10:
Make "no, keep playing" go back to pause menu This is so the menus can stack on top of each other. Well, technically they don't, but it's the same thing.
2020-06-23 05:58:09 +02:00
//return to pause menu
music.playef(11);
game.menupage = 31;
Use case-switch in mapmenuactionpress() This prevents from having to repeat 'if (game.menupage == ...)' everywhere, which makes for more concise code. I know you're technically supposed to indent the cases surrounded by if-guards, but I don't think indenting them here would help anything. I'd only indent it if the 'if' had an 'else', for example. But if it surrounds the whole case, then there's no need for indentation.
2020-06-23 00:35:26 +02:00
break;
case 11:
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
//quit to menu
//Kill contents of offset render buffer, since we do that for some reason.
//This fixes an apparent frame flicker.
Change all surface-clearing FillRect()s to use ClearSurface() ClearSurface() is less verbose than doing it the old way, and also conveys intent clearer. Plus, some of these FillRect()s had hardcoded width and height values, whereas ClearSurface() doesn't - meaning this change also has better future-proofing, in case the widths and heights of the surfaces involved change in the future.
2021-02-26 00:37:03 +01:00
ClearSurface(graphics.tempBuffer);
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
graphics.fademode = 2;
Revert hardcoded check for track 6 when quitting to menu This reverts commit 48313169b68f8ef8e6f83f29830b789061219ffd, "Don't fade music out when returning to the menu if it's Presenting VVVVVV". This commit is being reverted because it is only a single-case patch - that is, it fixes only a single symptom of the bug, and not its underlying cause.
2021-01-04 07:17:31 +01:00
music.fadeout();
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
map.nexttowercolour();
Restore janky gamestate-based quit-to-title system in glitchrunnermode This was fixed in 2.3 because one of the side effects of this janky system was being able to accidentally immediately quit to the title if the screen was black during a cutscene, which is something very likely to happen to casual players. Anyway, credits warp uses this gamestate-based system because it utilizes quitting to the title screen doing gamestate 80. From there, you increment the gamestate to gamestate 94 to use the Space Station 2 expo script.
2020-06-25 23:41:44 +02:00
if (!game.glitchrunnermode)
{
game.fadetomenu = true;
game.fadetomenudelay = 16;
}
Use case-switch in mapmenuactionpress() This prevents from having to repeat 'if (game.menupage == ...)' everywhere, which makes for more concise code. I know you're technically supposed to indent the cases surrounded by if-guards, but I don't think indenting them here would help anything. I'd only indent it if the 'if' had an 'else', for example. But if it surrounds the whole case, then there's no need for indentation.
2020-06-23 00:35:26 +02:00
break;
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
Use case-switch in mapmenuactionpress() This prevents from having to repeat 'if (game.menupage == ...)' everywhere, which makes for more concise code. I know you're technically supposed to indent the cases surrounded by if-guards, but I don't think indenting them here would help anything. I'd only indent it if the 'if' had an 'else', for example. But if it surrounds the whole case, then there's no need for indentation.
2020-06-23 00:35:26 +02:00
case 20:
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
//return to game
graphics.resumegamemode = true;
Use case-switch in mapmenuactionpress() This prevents from having to repeat 'if (game.menupage == ...)' everywhere, which makes for more concise code. I know you're technically supposed to indent the cases surrounded by if-guards, but I don't think indenting them here would help anything. I'd only indent it if the 'if' had an 'else', for example. But if it surrounds the whole case, then there's no need for indentation.
2020-06-23 00:35:26 +02:00
break;
case 21:
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
//quit to menu
game.swnmode = false;
graphics.fademode = 2;
music.fadeout();
Fix softlock if exiting Super Grav and bringing up map in glitchrunner The game would softlock if you brought up the map screen or quit screen after exiting the Super Gravitron to the Secret Lab. This softlock would only happen if you were in glitchrunner mode. This is because glitchrunner mode set game.fadetolabdelay when it shouldn't have, and also checked game.fadetolabdelay when it shouldn't have. So I made it so that the game will only set game.fadetolabdelay when not in glitchrunner mode (I already had a check for game.fadetomenudelay, too!) and the game will only check for game.fadetomenudelay and game.fadetolabdelay when not in glitchrunner mode, as well. I originally made the game check game.fadetomenudelay and game.fadetolabdelay to prevent being able to re-press ACTION to re-start the fadeout if the game was already fading out. And I made sure that this wasn't broken, both in glitchrunner mode and normal mode.
2020-07-17 00:11:54 +02:00
if (!game.glitchrunnermode)
{
game.fadetolab = true;
game.fadetolabdelay = 16;
}
Use case-switch in mapmenuactionpress() This prevents from having to repeat 'if (game.menupage == ...)' everywhere, which makes for more concise code. I know you're technically supposed to indent the cases surrounded by if-guards, but I don't think indenting them here would help anything. I'd only indent it if the 'if' had an 'else', for example. But if it surrounds the whole case, then there's no need for indentation.
2020-06-23 00:35:26 +02:00
break;
Make better Esc menu functional So now the options do what they do. However, I still need to fix the 1-frame glitch when switching to TITLEMODE, as well as make returning from the menu return back to MAPMODE, as well as making this better menu integrate seamlessly with the existing menus.
2020-06-23 00:47:25 +02:00
case 30:
// Return to game
graphics.resumegamemode = true;
break;
case 31:
// Go to quit prompt
music.playef(11);
game.menupage = 10;
break;
case 32:
case 33:
Consolidate common case 32/33 code If most of the code in the cases is the same, then just consolidate and de-duplicate them. It's less error-prone this way.
2020-06-23 01:52:40 +02:00
// Graphic options and game options
Make better Esc menu functional So now the options do what they do. However, I still need to fix the 1-frame glitch when switching to TITLEMODE, as well as make returning from the menu return back to MAPMODE, as well as making this better menu integrate seamlessly with the existing menus.
2020-06-23 00:47:25 +02:00
music.playef(11);
game.gamestate = TITLEMODE;
Fix Flip Mode persisting in in-game options menu Now graphics.flipmode is turned off when going into the menu, and turned back on if necessary when exiting.
2020-06-23 06:41:21 +02:00
graphics.flipmode = false;
Make returning from game/graphic options return to MAPMODE This is so return doesn't just lead back to more TITLEMODE.
2020-06-23 01:51:16 +02:00
game.ingame_titlemode = true;
Fix kludge_ingametemp being assigned after menu creation While working on #535, I noticed this bug. When going to Graphic Options or Game Options from the pause menu, kludge_ingametemp was intended to save the current menu stack frame BEFORE either of those menus got created. However, it was actually assigned afterwards, meaning kludge_ingametemp would always be either Menu::graphicoptions or Menu::options. This meant that the returntomenu() in returntopausemenu() would always attempt to return to the current in-game menu, and seeing as it's the same menu, would re-create the menu, instead of returning to the previous menu before it. This patch also fixes a potential source of a trivial memory leak, if someone were to keep entering and exiting Graphic Options or Game Options from the pause menu. It would keep piling up duplicate Graphic Options or Game Options stack frames, which would never get removed. However, they do get removed when you exit to the menu properly, by returntomenu() again, so this doesn't seem like that serious of an issue, but it's still good to fix.
2020-12-25 23:02:00 +01:00
// Set this before we create the menu
game.kludge_ingametemp = game.currentmenuname;
Consolidate common case 32/33 code If most of the code in the cases is the same, then just consolidate and de-duplicate them. It's less error-prone this way.
2020-06-23 01:52:40 +02:00
if (game.menupage == 32)
{
game.createmenu(Menu::graphicoptions);
}
else
{
game.createmenu(Menu::options);
}
Save BG vars to temp vars when entering menu and revert them upon exit Since the exact same tower background is also used on the menu, we need to save the current state of the background when entering the menu (before overwriting it), and then put it back when we're done. Maybe we ought to separate the in-game and menu tower backgrounds... This also fixes a semi-hilarious bug where you could make Panic Room go in the other direction by simply going to the options menu in-game. This is accomplished by adding convenience functions mapclass::bg_to_kludge() and mapclass::kludge_to_bg().
2020-06-23 02:14:01 +02:00
Round map.colstate to nearest 5 when entering options menus Also set map.tdrawback to true when leaving the menu. This is to fix the interpolated color of the tower background persisting, as well as making sure the menu background doesn't persist when exiting.
2020-06-23 05:49:16 +02:00
map.nexttowercolour();
Fix delta rendering glitch when going to options from new Esc menu Well this is a bit annoying. I can call graphics.updatetowerbackground() just fine, but I have to get at the title color update routine inside titlelogic(), which is hard-baked in. So I have to pull that code outside of the function, export it in the header, and then call it when I transition to TITLEMODE.
2020-06-23 01:41:07 +02:00
// Fix delta rendering glitch
Move title usages of towerbg to titlebg With the previous commit in place, we can now simply move some usages of the previous towerbg to use a separate object instead. That way, we don't have to mess with a monolithic state, or some better way to phrase what I just said, and we instead have two separate objects that can coexist side-by-side.
2020-11-03 00:23:53 +01:00
graphics.updatetowerbackground(graphics.titlebg);
Fix delta rendering glitch when going to options from new Esc menu Well this is a bit annoying. I can call graphics.updatetowerbackground() just fine, but I have to get at the title color update routine inside titlelogic(), which is hard-baked in. So I have to pull that code outside of the function, export it in the header, and then call it when I transition to TITLEMODE.
2020-06-23 01:41:07 +02:00
titleupdatetextcol();
Make better Esc menu functional So now the options do what they do. However, I still need to fix the 1-frame glitch when switching to TITLEMODE, as well as make returning from the menu return back to MAPMODE, as well as making this better menu integrate seamlessly with the existing menus.
2020-06-23 00:47:25 +02:00
break;
Unindent mapmenuactionpress() Done in a separate commit to minimize diff noise.
2020-06-23 00:31:14 +02:00
}
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 teleporterinput(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Todo Mouseinput!
//game.mx = (mouseX / 2);
//game.my = (mouseY / 2);
int tempx, tempy;
game.press_left = false;
game.press_right = false;
game.press_action = false;
game.press_map = false;
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
if(graphics.menuoffset==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (key.isDown(KEYBOARD_LEFT)|| key.isDown(KEYBOARD_a) || key.controllerWantsLeft(false) ) game.press_left = true;
if (key.isDown(KEYBOARD_RIGHT) || key.isDown(KEYBOARD_d)|| key.controllerWantsRight(false) ) game.press_right = true;
if (key.isDown(KEYBOARD_z) || key.isDown(KEYBOARD_SPACE) || key.isDown(KEYBOARD_v)
|| key.isDown(KEYBOARD_UP) || key.isDown(KEYBOARD_DOWN)|| key.isDown(KEYBOARD_w)|| key.isDown(KEYBOARD_s) || key.isDown(game.controllerButton_flip)) game.press_action = true;
if (key.isDown(KEYBOARD_ENTER) || key.isDown(game.controllerButton_map)) game.press_map = true;
//In the menu system, all keypresses are single taps rather than holds. Therefore this test has to be done for all presses
if (!game.press_action && !game.press_left && !game.press_right) game.jumpheld = false;
if (!game.press_map) game.mapheld = false;
Add being able to press Esc to go to quit menu from teleporter menu It's always been a bit annoying that if you're in the teleporter menu, you can't press Escape to go to the "Do you want to quit?" menu.
2020-06-21 02:34:45 +02:00
if (key.isDown(27))
{
Allow pressing Enter on teleporters during playtesting There's no reason you shouldn't be allowed to press Enter on teleporters during playtesting. Well, except that you can press Esc in the teleporter menu in order to go to the pause menu, which isn't intended in playtesting. But I can just add a check there so that pressing Esc closes the teleporter menu instead, it's fine.
2020-07-11 09:15:06 +02:00
if (!map.custommode || map.custommodeforreal)
{
Fix pressing Esc in teleporter menu going to quit screen When I added the new pause menu, I forgot to make pressing Esc in the teleporter menu go to the new pause menu instead. But it's fixed now.
2020-07-11 09:21:23 +02:00
// Go to pause menu
Allow pressing Enter on teleporters during playtesting There's no reason you shouldn't be allowed to press Enter on teleporters during playtesting. Well, except that you can press Esc in the teleporter menu in order to go to the pause menu, which isn't intended in playtesting. But I can just add a check there so that pressing Esc closes the teleporter menu instead, it's fine.
2020-07-11 09:15:06 +02:00
game.mapheld = true;
Fix pressing Esc in teleporter menu going to quit screen When I added the new pause menu, I forgot to make pressing Esc in the teleporter menu go to the new pause menu instead. But it's fixed now.
2020-07-11 09:21:23 +02:00
game.menupage = 30;
Allow pressing Enter on teleporters during playtesting There's no reason you shouldn't be allowed to press Enter on teleporters during playtesting. Well, except that you can press Esc in the teleporter menu in order to go to the pause menu, which isn't intended in playtesting. But I can just add a check there so that pressing Esc closes the teleporter menu instead, it's fine.
2020-07-11 09:15:06 +02:00
game.gamestate = MAPMODE;
}
else
{
// Close teleporter menu
graphics.resumegamemode = true;
}
Add being able to press Esc to go to quit menu from teleporter menu It's always been a bit annoying that if you're in the teleporter menu, you can't press Escape to go to the "Do you want to quit?" menu.
2020-06-21 02:34:45 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
game.mapheld = true;
game.jumpheld = true;
}
if (!game.jumpheld)
{
if (game.press_action || game.press_left || game.press_right || game.press_map)
{
game.jumpheld = true;
}
Fix infinite loop pressing left/right in tele menu w/ no teles unlocked This infinite loop would occur because once you pressed left or right, the game keeps searching through all the list of teleporters until it finds one that is unlocked. But if there's none that are unlocked, then the game goes into an infinite loop, which brings up the Not Responding dialog on Windows so you can kill it. Normally, you're not supposed to have no teleporters unlocked while being able to access a teleporter, but you can achieve this by going to Class Dismissed from a custom level (while making sure you don't start in 0,0, because there's a teleporter there that you would unlock). The solution is to make sure at least one teleporter is unlocked before doing any searching.
2020-07-05 03:58:13 +02:00
bool any_tele_unlocked = false;
if (game.press_left || game.press_right)
{
for (size_t i = 0; i < map.teleporters.size(); i++)
{
point& tele = map.teleporters[i];
if (map.explored[tele.x + tele.y*20])
{
any_tele_unlocked = true;
break;
}
}
}
if (game.press_left && any_tele_unlocked)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use proper do-while for teleporter searching loop A do-while is just a while-loop, but the inner block will always run once before the conditional is checked. It looks like in order to achieve this desired behavior (always run the block once before checking the conditional), instead of using a do-while loop, Terry just used a normal while-loop and copy-pasted the inner block on the outside. So I'm de-duplicating the code.
2020-07-05 03:50:58 +02:00
do
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
game.teleport_to_teleporter--;
Remove map.numteleporters This removes the separate length-tracking variable map.numteleporters, in favor of using map.teleporters.size().
2020-04-15 04:32:30 +02:00
if (game.teleport_to_teleporter < 0) game.teleport_to_teleporter = map.teleporters.size() - 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tempx = map.teleporters[game.teleport_to_teleporter].x;
tempy = map.teleporters[game.teleport_to_teleporter].y;
}
Use proper do-while for teleporter searching loop A do-while is just a while-loop, but the inner block will always run once before the conditional is checked. It looks like in order to achieve this desired behavior (always run the block once before checking the conditional), instead of using a do-while loop, Terry just used a normal while-loop and copy-pasted the inner block on the outside. So I'm de-duplicating the code.
2020-07-05 03:50:58 +02:00
while (map.explored[tempx + (20 * tempy)] == 0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Fix infinite loop pressing left/right in tele menu w/ no teles unlocked This infinite loop would occur because once you pressed left or right, the game keeps searching through all the list of teleporters until it finds one that is unlocked. But if there's none that are unlocked, then the game goes into an infinite loop, which brings up the Not Responding dialog on Windows so you can kill it. Normally, you're not supposed to have no teleporters unlocked while being able to access a teleporter, but you can achieve this by going to Class Dismissed from a custom level (while making sure you don't start in 0,0, because there's a teleporter there that you would unlock). The solution is to make sure at least one teleporter is unlocked before doing any searching.
2020-07-05 03:58:13 +02:00
else if (game.press_right && any_tele_unlocked)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use proper do-while for teleporter searching loop A do-while is just a while-loop, but the inner block will always run once before the conditional is checked. It looks like in order to achieve this desired behavior (always run the block once before checking the conditional), instead of using a do-while loop, Terry just used a normal while-loop and copy-pasted the inner block on the outside. So I'm de-duplicating the code.
2020-07-05 03:50:58 +02:00
do
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
game.teleport_to_teleporter++;
Remove map.numteleporters This removes the separate length-tracking variable map.numteleporters, in favor of using map.teleporters.size().
2020-04-15 04:32:30 +02:00
if (game.teleport_to_teleporter >= (int) map.teleporters.size()) game.teleport_to_teleporter = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tempx = map.teleporters[game.teleport_to_teleporter].x;
tempy = map.teleporters[game.teleport_to_teleporter].y;
}
Use proper do-while for teleporter searching loop A do-while is just a while-loop, but the inner block will always run once before the conditional is checked. It looks like in order to achieve this desired behavior (always run the block once before checking the conditional), instead of using a do-while loop, Terry just used a normal while-loop and copy-pasted the inner block on the outside. So I'm de-duplicating the code.
2020-07-05 03:50:58 +02:00
while (map.explored[tempx + (20 * tempy)] == 0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if (game.press_map)
{
tempx = map.teleporters[game.teleport_to_teleporter].x;
tempy = map.teleporters[game.teleport_to_teleporter].y;
if (game.roomx == tempx + 100 && game.roomy == tempy + 100)
{
//cancel!
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
graphics.resumegamemode = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
//teleport
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
graphics.resumegamemode = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.teleport_to_x = tempx;
game.teleport_to_y = tempy;
//trace(game.recordstring);
//We're teleporting! Yey!
game.activetele = false;
game.hascontrol = false;
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].colour = 102;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
i = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getteleporter() is used unchecked obj.getteleporter() is able to return -1. If there's no check on it, it will end up indexing out-of-bounds, which is Undefined Behavior.
2020-06-13 04:31:08 +02:00
{
obj.entities[i].tile = 6;
obj.entities[i].colour = 102;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//which teleporter script do we use? it depends on the companion!
game.state = 4000;
game.statedelay = 0;
}
}
}
}
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 gamecompleteinput(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
game.press_left = false;
game.press_right = false;
game.press_action = false;
game.press_map = false;
Fix credits position being 1 frame off w/ BG when press/release ACTION When you pressed and released ACTION to speed up the credits, the credits position would end up being 1 frame off from the background. This is due to the fact that we update the tower background after we update the credits position, so this commit moves the tower background update before the credits position update.
2020-04-30 20:13:02 +02:00
//Do this before we update map.bypos
if (!game.colourblindmode)
{
Move title usages of towerbg to titlebg With the previous commit in place, we can now simply move some usages of the previous towerbg to use a separate object instead. That way, we don't have to mess with a monolithic state, or some better way to phrase what I just said, and we instead have two separate objects that can coexist side-by-side.
2020-11-03 00:23:53 +01:00
graphics.updatetowerbackground(graphics.titlebg);
Fix credits position being 1 frame off w/ BG when press/release ACTION When you pressed and released ACTION to speed up the credits, the credits position would end up being 1 frame off from the background. This is due to the fact that we update the tower background after we update the credits position, so this commit moves the tower background update before the credits position update.
2020-04-30 20:13:02 +02:00
}
Interpolate credits position So that it's as smooth as possible, especially when holding down ACTION to make it go really fast.
2020-04-30 19:56:27 +02:00
//Do these here because input comes first
Move title usages of towerbg to titlebg With the previous commit in place, we can now simply move some usages of the previous towerbg to use a separate object instead. That way, we don't have to mess with a monolithic state, or some better way to phrase what I just said, and we instead have two separate objects that can coexist side-by-side.
2020-11-03 00:23:53 +01:00
graphics.titlebg.bypos += graphics.titlebg.bscroll;
Interpolate credits position So that it's as smooth as possible, especially when holding down ACTION to make it go really fast.
2020-04-30 19:56:27 +02:00
game.oldcreditposition = game.creditposition;
Don't re-draw credits scroll background every frame While I was working on my over-30-FPS patch, I found out that the tower background in the credits scroll was being completely re-drawn every single frame, which was a bit wasteful and expensive. It's also harder to interpolate for my over-30-FPS patch. I'm guessing this constant re-draw was done because the math to get the surface scroll properly working is a bit subtle, but I've figured the precise math out! The first changes of this patch is just removing the unconditional `map.tdrawback = true;`, and having to set `map.scrolldir` everywhere to get the credits scrolling in the right direction but make sure the title screen doesn't start scrolling like a descending tower, too. After that, the first problem is that it looks like the ACTION press to speed up the credits scrolling doesn't speed up the background, too. No problem, just shove a `!game.press_action` check in `gamecompletelogic()`. However, this introduces a mini-problem, which is that NOW when you hold down ACTION, the background appears to be slowly getting out of sync with the credits text by a one-pixel-per-second difference. This is actually due to the fact that, as a result of me adding the conditional, `map.bscroll` is no longer always unconditionally getting set to 1, while `game.creditposition` IS always unconditionally getting decremented by 1. And when you hold down ACTION, `game.creditposition` gets decremented by 6. Thus, I need to set `map.bscroll` when holding down ACTION to be 7, which is 6 plus 1. Then we have another problem, which is that the incoming textures desync when you press ACTION, and when you release ACTION. They desync by precisely 6 pixels, which should be a familiar number. I (eventually) tracked this down to `map.bypos` being updated at the same time `map.bscroll` is, even though `map.bypos` should be updated a frame later AFTER updating `map.bscroll`. So I had to change the `map.bypos` update in `gamecompleteinput()` and `gamecompletelogic()` to be `map.bypos += map.bscroll;` and then place it before any `map.bscroll` update, thus ensuring that `map.bscroll` updates exactly one frame before `map.ypos` does. I had to move the `map.bypos += map.bscroll;` to be in `gamecompleteinput()`, because `gamecompleteinput()` comes first before `gamecompletelogic()` in the `main.cpp` game loop, otherwise the `map.bypos` update won't be delayed by one frame for when you press ACTION to make it go faster, and thus cause a desync when you press ACTION. Oh and then after that, I had to make the descending tower background draw a THIRD row of incoming tiles, otherwise you could see some black flickering at the bottom of the screen when you held down ACTION. All of this took me way too long to figure out, but now the credits scroll works perfectly while being more optimized.
2020-04-30 05:52:33 +02:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (key.isDown(KEYBOARD_z) || key.isDown(KEYBOARD_SPACE) || key.isDown(KEYBOARD_v) || key.isDown(game.controllerButton_flip))
{
game.creditposition -= 6;
Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
if (game.creditposition <= -Credits::creditmaxposition)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
if(graphics.fademode==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
game.creditposition = -Credits::creditmaxposition;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Move title usages of towerbg to titlebg With the previous commit in place, we can now simply move some usages of the previous towerbg to use a separate object instead. That way, we don't have to mess with a monolithic state, or some better way to phrase what I just said, and we instead have two separate objects that can coexist side-by-side.
2020-11-03 00:23:53 +01:00
graphics.titlebg.bscroll = +7;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
game.press_action = true;
}
if (key.isDown(KEYBOARD_ENTER)|| key.isDown(game.controllerButton_map)) game.press_map = true;
if (!game.mapheld)
{
if(game.press_map)
{
//Return to game
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
if(graphics.fademode==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
graphics.fademode = 2;
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 gamecompleteinput2(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
game.press_left = false;
game.press_right = false;
game.press_action = false;
game.press_map = false;
Interpolate end picture reveal scroll This is so it looks smooth at framerates above 30.
2020-05-02 03:23:52 +02:00
//Do this here because input comes first
game.oldcreditposx = game.creditposx;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (key.isDown(KEYBOARD_z) || key.isDown(KEYBOARD_SPACE) || key.isDown(KEYBOARD_v) || key.isDown(game.controllerButton_flip))
{
game.creditposx++;
Interpolate end picture reveal scroll This is so it looks smooth at framerates above 30.
2020-05-02 03:23:52 +02:00
game.oldcreditposx++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.creditposy >= 30)
{
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
if(graphics.fademode==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.fadeout();
}
}
game.press_action = true;
}
if (key.isDown(KEYBOARD_ENTER) || key.isDown(game.controllerButton_map)) game.press_map = true;
if (!game.mapheld)
{
if(game.press_map)
{
//Return to game
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
if(graphics.fademode==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove global args from Input.cpp This removes all global args from functions in Input.cpp. Additionally, 'dwgfx' has been renamed to 'graphics' in Input.cpp.
2020-04-01 23:52:45 +02:00
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.fadeout();
}
}
}
}
Reference in a new issue Copy permalink