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

2120 lines
66 KiB
C++
Raw Normal View History

Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "Input.h"
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
#include "Script.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "MakeAndPlay.h"
#include "tinyxml.h"
Replace TiXmlDocument load and save functions by PHYSFS The TinyXml functions to load and save files don't properly support unicode file paths on Windows, so in order to support that properly, I saw no other option than to do the actual loading and saving via PHYSFS (or to use the Windows API on Windows and retain doc.LoadFile and doc.SaveFile on other OSes, but that'd be more complicated and unnecessary, we already have PHYSFS, right?). There are two new functions in FileSystemUtils: bool FILESYSTEM_saveTiXmlDocument(const char *name, TiXmlDocument *doc) bool FILESYSTEM_loadTiXmlDocument(const char *name, TiXmlDocument *doc) Any instances of doc.SaveFile(<FULL_PATH>) have been replaced by FILESYSTEM_saveTiXmlDocument(<VVVVVV_FOLDER_PATH>, &doc), where <FULL_PATH> included the full path to the saves or levels directory, and <VVVVVV_FOLDER_PATH> only includes the path relative to the VVVVVV directory. When loading a document, a TiXmlDocument used to be created with a full path in its constructor and doc.LoadFile() would then be called, now a TiXmlDocument is constructed with no path name and FILESYSTEM_loadTiXmlDocument(<VVVVVV_FOLDER_PATH>, &doc) is called.
2020-01-12 15:17:39 +01:00
#include "FileSystemUtils.h"
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
extern scriptclass script;
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
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);
}
}
}
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);
}
}
}
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);
}
}
}
}
}
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
void 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::mainmenu)
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
#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
if (game.telesummary == "" && game.quicksummary == "")
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
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
}
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
#if !defined(NO_CUSTOM_LEVELS)
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
else if(game.currentmenuname==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);
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();
}else if(game.currentmenuoption==(int)game.menuoptions.size()-2){
//next page
music.playef(11);
if((size_t) ((game.levelpage*8)+8) >= ed.ListOfMetaData.size()){
game.levelpage=0;
}else{
game.levelpage++;
}
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
game.currentmenuoption=game.menuoptions.size()-2;
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";
TiXmlDocument doc;
if (!FILESYSTEM_loadTiXmlDocument(name.c_str(), &doc)){
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();
}
}
}
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
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
else if(game.currentmenuname==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
{
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
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
game.levelpage=0;
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;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
#if !defined(NO_CUSTOM_LEVELS)
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
else if(game.currentmenuname==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
{
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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
//"OPENFOLDERHOOK"
//When the player selects the "open level folder" menu option,
//this is where it should run the appropriate code.
//This code should:
// - Minimise the game
// - Open the levels folder for whatever operating system we're on
SDL_assert(0 && "Remove open level dir");
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+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);
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
}
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
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
#endif
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
else if(game.currentmenuname==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();
}
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
else if (game.currentmenuname == 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
{
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();
game.fullscreen = !game.fullscreen;
game.savestats();
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
game.currentmenuoption = 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
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();
game.stretchMode = (game.stretchMode + 1) % 3;
game.savestats();
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
game.currentmenuoption = 1;
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);
graphics.screenbuffer->toggleLinearFilter();
game.useLinearFilter = !game.useLinearFilter;
game.savestats();
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
game.currentmenuoption = 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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
game.fullScreenEffect_badSignal = !game.fullScreenEffect_badSignal;
//Hook the analogue thing in here: ABCDEFG
graphics.screenbuffer->badSignalEffect= !graphics.screenbuffer->badSignalEffect;
game.savestats();
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
game.currentmenuoption = 3;
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
//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;
}
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);
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
}
}
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
else if (game.currentmenuname == Menu::youwannaquit)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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);
game.createmenu(game.previousmenuname);
map.nexttowercolour();
}
}
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
else if (game.currentmenuname == Menu::setinvincibility)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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);
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
game.currentmenuoption = 3;
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;
game.savestats();
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
game.currentmenuoption = 3;
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
}
}
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
else if (game.currentmenuname == Menu::setslowdown1)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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);
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
game.currentmenuoption = 4;
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
//change game speed
game.deletequick();
game.deletetele();
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::setslowdown2);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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();
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;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02: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
else if (game.currentmenuname == Menu::setslowdown2)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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.gameframerate=34;
game.slowdown = 30;
game.savestats();
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
game.currentmenuoption = 4;
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
game.gameframerate=41;
game.slowdown = 24;
game.savestats();
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
game.currentmenuoption = 4;
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
game.gameframerate=55;
game.slowdown = 18;
game.savestats();
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
game.currentmenuoption = 4;
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 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.gameframerate=83;
game.slowdown = 12;
game.savestats();
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
game.currentmenuoption = 4;
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
}
}
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
else if (game.currentmenuname == 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
{
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;
game.savestats();
map.tdrawback = true;
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;
game.savestats();
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;
game.savestats();
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
if (!map.invincibility)
{
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::setinvincibility);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
{
map.invincibility = !map.invincibility;
}
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 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
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::setslowdown2);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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();
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 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
// toggle fake load screen
game.skipfakeload = !game.skipfakeload;
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 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
// toggle translucent roomname BG
graphics.translucentroomname = !graphics.translucentroomname;
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 7:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
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;
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
}
}
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
else if (game.currentmenuname == 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)
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 OFFSET -1
#else
#define OFFSET 0
#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
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;
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 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 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();
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
//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;
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
//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();
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
int mmmmmm_offset = music.mmmmmm ? 0 : -1;
if (game.currentmenuoption == OFFSET+4+mmmmmm_offset)
{
//**** TOGGLE MMMMMM
if(game.usingmmmmmm > 0){
game.usingmmmmmm=0;
}else{
game.usingmmmmmm=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
}
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
music.usingmmmmmm = !music.usingmmmmmm;
music.playef(11);
music.play(6);
game.savestats();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
else if (game.currentmenuoption == OFFSET+5+mmmmmm_offset)
{
//back
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);
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
map.nexttowercolour();
}
#undef 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
}
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
else if (game.currentmenuname == 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
{
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);
game.savestats();
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
game.currentmenuoption = 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
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);
game.savestats();
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
game.currentmenuoption = 1;
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);
game.savestats();
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
game.currentmenuoption = 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: //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);
game.savestats();
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
game.currentmenuoption = 3;
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);
game.savestats();
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
game.currentmenuoption = 4;
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);
game.savestats();
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
game.currentmenuoption = 5;
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);
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();
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
}
}
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
else if (game.currentmenuname == 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
{
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;
game.savestats();
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
game.currentmenuoption = 1;
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;
game.savestats();
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
game.currentmenuoption = 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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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;
game.savestats();
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
game.currentmenuoption = 3;
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;
game.savestats();
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
game.currentmenuoption = 4;
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;
game.savestats();
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
game.currentmenuoption = 5;
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);
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;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02: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
else if (game.currentmenuname == 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
{
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);
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::credits2);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
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
}
}
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
else if (game.currentmenuname == Menu::credits2)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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);
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::credits25);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
//back
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();
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
}
}
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
else if (game.currentmenuname == Menu::credits25)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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);
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::credits3);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
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
}
}
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
else if (game.currentmenuname == Menu::credits3)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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;
if (game.current_credits_list_index >= (int)game.superpatrons.size())
{
// No more super patrons. Move to the next credits section
game.current_credits_list_index = 0;
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::credits4);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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::credits3);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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;
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
}
}
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
else if (game.currentmenuname == Menu::credits4)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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;
if (game.current_credits_list_index >= (int)game.patrons.size())
{
// No more patrons. Move to the next credits section
game.current_credits_list_index = 0;
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::credits5);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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::credits4);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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;
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
}
}
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
else if (game.currentmenuname == Menu::credits5)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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;
if (game.current_credits_list_index >= (int)game.githubfriends.size())
{
// No more GitHub contributors. Move to the next credits section
game.current_credits_list_index = 0;
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::credits6);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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::credits5);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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;
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
}
}
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
else if (game.currentmenuname == Menu::credits6)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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);
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;
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);
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();
music.niceplay(6);
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
}
}
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
else if (game.currentmenuname == 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?
int offset = game.unlock[8] ? 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
if (game.telesummary == "")
{
//You at least have a quicksave, or you couldn't have gotten here
game.mainmenu = 2;
graphics.fademode = 2;
}
else if (game.quicksummary == "")
{
//You at least have a telesave, or you couldn't have gotten here
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
map.settowercolour(3);
}
}
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){
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
}
}
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 == 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
{
//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();
}
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 == 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
{
//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();
}
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 == 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
{
//back
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();
}
}
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
else if (game.currentmenuname == 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
{
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
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);
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;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02: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
else if (game.currentmenuname == 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
{
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
game.controllerSensitivity++;
music.playef(11);
if(game.controllerSensitivity > 4)
{
game.controllerSensitivity = 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
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 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 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
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);
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
}
}
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
else if (game.currentmenuname == 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
{
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);
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;
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();
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
}
}
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
else if (game.currentmenuname == 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
{
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
{
music.playef(18);
game.screenshake = 10;
game.flashlight = 5;
graphics.setflipmode = !graphics.setflipmode;
game.savemystats = true;
}
else if (game.currentmenuoption == 4)
{
//back
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();
}
else
{
//Can't do yet! play sad sound
music.playef(2);
}
}
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
else if (game.currentmenuname == 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
{
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
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
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;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02: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
else if (game.currentmenuname == 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
{
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
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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
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;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02: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
else if (game.currentmenuname == 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
{
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);
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;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02: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
else if (game.currentmenuname == 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
{
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
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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
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;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02: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
else if (game.currentmenuname == 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
{
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
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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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:
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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);
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;
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02: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
else if (game.currentmenuname == 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);
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();
}
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
else if (game.currentmenuname == Menu::unlocktimetrials
|| game.currentmenuname == Menu::unlocktimetrial
|| game.currentmenuname == Menu::unlocknodeathmode
|| game.currentmenuname == Menu::unlockintermission
|| game.currentmenuname == 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);
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();
}
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
else if (game.currentmenuname == 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
{
game.mainmenu = 3;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 1 && game.unlock[10]) //lab
{
game.mainmenu = 4;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 2 && game.unlock[11]) //tower
{
game.mainmenu = 5;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 3 && game.unlock[12]) //station 2
{
game.mainmenu = 6;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 4 && game.unlock[13]) //warp
{
game.mainmenu = 7;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 5 && game.unlock[14]) //final
{
game.mainmenu = 8;
graphics.fademode = 2;
}
else if (game.currentmenuoption == 6) //go to the time trial menu
{
//back
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();
}
else
{
//Can't do yet! play sad sound
music.playef(2);
}
}
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
else if (game.currentmenuname == Menu::timetrialcomplete3)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
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);
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;
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
//duplicate the above based on given time trial level!
if (game.timetriallevel == 0) //space station 1
{
game.mainmenu = 3;
graphics.fademode = 2;
}
else if (game.timetriallevel == 1) //lab
{
game.mainmenu = 4;
graphics.fademode = 2;
}
else if (game.timetriallevel == 2) //tower
{
game.mainmenu = 5;
graphics.fademode = 2;
}
else if (game.timetriallevel == 3) //station 2
{
game.mainmenu = 6;
graphics.fademode = 2;
}
else if (game.timetriallevel == 4) //warp
{
game.mainmenu = 7;
graphics.fademode = 2;
}
else if (game.timetriallevel == 5) //final
{
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
}
}
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
else if (game.currentmenuname == Menu::gamecompletecontinue || game.currentmenuname == Menu::nodeathmodecomplete2)
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
music.play(6);
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);
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();
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though I'd want it the other way around, otherwise titleinput() won't know what it is.
2020-04-15 19:14:42 +02:00
void titleinput()
{
//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
//TODO bit wasteful doing this every poll
key.setSensitivity(game.controllerSensitivity);
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);
game.previousmenuname = game.currentmenuname;
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::youwannaquit);
Move menu ACTION press handling to separate function This takes out 3 indentation levels from the ACTION press handling, making titleinput() easier to read as a whole. Unfortunately, we have to put menuactionpress() first, even though 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();
}
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;
map.colstate = 10;
map.nexttowercolour();
}
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 &&
game.currentmenuoption < 4 &&
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
}
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
void gameinput()
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;
game.press_map = 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;
};
if (key.isDown(KEYBOARD_ENTER) || key.isDown(SDLK_KP_ENTER) || key.isDown(game.controllerButton_map) )
{
game.press_map = 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
}
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
{
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(!game.glitchrunkludge) game.state++;
game.jumpheld = true;
game.glitchrunkludge=true;
//Bug fix! You should only be able to do this ONCE.
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
if (!game.press_map) game.mapheld = 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 (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){
game.mapheld = true;
//Return to level editor
if (game.activeactivity > -1 && game.press_map){
if((int(std::abs(obj.entities[obj.getplayer()].vx))<=1) && (int(obj.entities[obj.getplayer()].vy) == 0) )
{
script.load(obj.blocks[game.activeactivity].script);
obj.removeblock(game.activeactivity);
game.activeactivity = -1;
}
}else{
game.gamestate = EDITORMODE;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
graphics.textboxremove();
game.hascontrol = true;
game.advancetext = false;
game.completestop = false;
game.state = 0;
graphics.showcutscenebars = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
graphics.backgrounddrawn=false;
music.fadeout();
//If warpdir() is used during playtesting, we need to set it back after!
for (int j = 0; j < ed.maxheight; j++)
{
for (int i = 0; i < ed.maxwidth; i++)
{
ed.level[i+(j*ed.maxwidth)].warpdir=ed.kludgewarpdir[i+(j*ed.maxwidth)];
}
}
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
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)
{
if (game.press_map && !game.mapheld)
{
game.mapheld = true;
if (game.activetele && game.readytotele > 20 && !game.intimetrial)
{
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.flipmode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Declare obj.flags a vector of bools instead of ints It's treated like a bool anyway, so might as well make it one. This also necessitates updating every single instance where it or an element inside it is used, too.
2020-04-09 08:34:26 +02:00
obj.flags[73] = true; //Flip mode test
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if(int(std::abs(obj.entities[ie].vx))<=1 && int(obj.entities[ie].vy)==0)
{
//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();
obj.entities[player].colour = 102;
int teleporter = obj.getteleporter();
obj.entities[teleporter].tile = 6;
obj.entities[teleporter].colour = 102;
//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
game.gamestate = 5;
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.menuoffset = 240; //actually this should count the roomname
if (map.extrarow) graphics.menuoffset -= 10;
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
BlitSurfaceStandard(graphics.menubuffer,NULL,graphics.backBuffer, NULL);
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.resumegamemode = false;
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();
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();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if(companion>-1) obj.entities[companion].colour = 102;
int teleporter = obj.getteleporter();
obj.entities[teleporter].tile = 6;
obj.entities[teleporter].colour = 102;
//which teleporter script do we use? it depends on the companion!
game.state = 3000;
game.statedelay = 0;
}
}
}
else if (game.activeactivity > -1)
{
if((int(std::abs(obj.entities[ie].vx))<=1) && (int(obj.entities[ie].vy) == 0) )
{
script.load(obj.blocks[game.activeactivity].script);
obj.removeblock(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
}
}
else if (game.swnmode == 1 && game.swngame == 1)
{
//quitting the super gravitron
game.mapheld = true;
//Quit menu, same conditions as in game menu
game.gamestate = MAPMODE;
game.gamesaved = 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
graphics.resumegamemode = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.menupage = 20; // The Map Page
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
BlitSurfaceStandard(graphics.menubuffer,NULL,graphics.backBuffer, NULL);
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.menuoffset = 240; //actually this should count the roomname
if (map.extrarow) graphics.menuoffset -= 10;
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
else if (game.intimetrial && graphics.fademode==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Quick restart of time trial
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.hardreset();
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.setflipmode) graphics.flipmode = true;
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.completestop = true;
music.fadeout();
game.intimetrial = true;
game.quickrestartkludge = true;
}
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
else if (graphics.fademode==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Normal map screen, do transition later
game.gamestate = MAPMODE;
map.cursordelay = 0;
map.cursorstate = 0;
game.gamesaved = 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
graphics.resumegamemode = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.menupage = 0; // The Map Page
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
BlitSurfaceStandard(graphics.menubuffer,NULL,graphics.backBuffer, NULL);
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.menuoffset = 240; //actually this should count the roomname
if (map.extrarow) graphics.menuoffset -= 10;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
if ((key.isDown(27) || key.isDown(game.controllerButton_esc)) && (!map.custommode || map.custommodeforreal))
{
game.mapheld = true;
//Quit menu, same conditions as in game menu
game.gamestate = MAPMODE;
game.gamesaved = 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
graphics.resumegamemode = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.menupage = 10; // The Map Page
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
BlitSurfaceStandard(graphics.menubuffer,NULL,graphics.backBuffer, NULL);
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.menuoffset = 240; //actually this should count the roomname
if (map.extrarow) graphics.menuoffset -= 10;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if (key.keymap[SDLK_r] && game.deathseq<=0)// && map.custommode) //Have fun glitchrunners!
{
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.deathseq = 30;
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++;
}
}
}
else
{
//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;
}
}
}
}
}
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
void mapinput()
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;
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
{
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.flipmode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (key.isDown(KEYBOARD_LEFT) || key.isDown(KEYBOARD_DOWN) || key.isDown(KEYBOARD_a) || key.isDown(KEYBOARD_s) || key.controllerWantsLeft(false) ) game.press_left = true;
if (key.isDown(KEYBOARD_RIGHT) || key.isDown(KEYBOARD_UP) || key.isDown(KEYBOARD_d) || key.isDown(KEYBOARD_w) || key.controllerWantsRight(false)) game.press_right = true;
}
else
{
if (key.isDown(KEYBOARD_LEFT) || key.isDown(KEYBOARD_UP) || key.isDown(KEYBOARD_a) || key.isDown(KEYBOARD_w)|| key.controllerWantsLeft(false))
{
game.press_left = true;
}
if (key.isDown(KEYBOARD_RIGHT) || key.isDown(KEYBOARD_DOWN) || key.isDown(KEYBOARD_d) || key.isDown(KEYBOARD_s)|| key.controllerWantsRight(false))
{
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;
}
if (game.menupage < 9)
{
if (key.isDown(KEYBOARD_ENTER) || key.isDown(game.controllerButton_map) ) game.press_map = true;
if (key.isDown(27))
{
game.mapheld = true;
game.menupage = 10;
}
}
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
}
}
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)
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
FillRect(graphics.menubuffer, 0x000000);
graphics.resumegamemode = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.removeallblocks();
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
game.menukludge = false;
if (game.menupage >= 20)
{
game.state = 96;
game.statedelay = 0;
}
else
{
game.state = 80;
game.statedelay = 0;
}
}
if (!game.jumpheld)
{
if (game.press_action || game.press_left || game.press_right || game.press_map)
{
game.jumpheld = true;
}
if (game.press_left)
{
game.menupage--;
}
else if (game.press_right)
{
game.menupage++;
}
Declare obj.flags a vector of bools instead of ints It's treated like a bool anyway, so might as well make it one. This also necessitates updating every single instance where it or an element inside it is used, too.
2020-04-09 08:34:26 +02:00
if (game.menupage == 1 && obj.flags[67] && game.press_action && !game.insecretlab && !map.custommode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Warp back to the ship
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 = 2;
game.teleport_to_y = 11;
//trace(game.recordstring);
//We're teleporting! Yey!
game.activetele = false;
game.hascontrol = false;
int i = obj.getplayer();
obj.entities[i].colour = 102;
//which teleporter script do we use? it depends on the companion!
game.state = 4000;
game.statedelay = 0;
}
if (game.menupage == 3 && !game.gamesaved && game.press_action && !game.intimetrial
&& !game.nodeathmode && !game.insecretlab && !game.inintermission)
{
game.flashlight = 5;
game.screenshake = 10;
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(18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.gamesaved = 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.savetime = game.timestring();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.savearea = map.currentarea(map.area(game.roomx, game.roomy));
Don't use separate variable for number of collected trinkets game.trinkets is supposed to be correlated with obj.collect, however why not just count obj.collect directly? This turns game.trinkets into a function, game.trinkets(), which will directly count the number of collected trinkets and return it. This will fix a few corner cases where the number of trinkets can desync with the actual collection statuses of trinkets. In order to keep save compatibility with previous versions of VVVVVV, the game will still write the <trinkets> variable. However, it will not read the <trinkets> variable from a save file.
2020-04-07 08:46:27 +02:00
game.savetrinkets = game.trinkets();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.roomx >= 102 && game.roomx <= 104 && game.roomy >= 110 && game.roomy <= 111) game.savearea = "The Ship";
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)
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
if(map.custommodeforreal)
{
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.customsavequick(ed.ListOfMetaData[game.playcustomlevel].filename);
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
}
else
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
Add option to compile without the level editor
2020-02-10 01:53:01 +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
game.savequick();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
if (game.menupage == 10 && game.press_action)
{
//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
graphics.resumegamemode = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if (game.menupage == 11 && game.press_action)
{
//quit to menu
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
{
Fix mixed indentation in Input.cpp There is a lot to be had for this one.
2020-04-02 23:06:56 +02:00
//Kill contents of offset render buffer, since we do that for some reason.
//This fixes an apparent frame flicker.
FillRect(graphics.tempBuffer, 0x000000);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.intimetrial || game.insecretlab || game.nodeathmode) game.menukludge = true;
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.hardreset();
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.setflipmode) graphics.flipmode = true;
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.fadeout();
Call nexttowercolour() when exiting to menu This fixes a bug where you could get mismatched text and background colors on the menu screen by being in the Tower and exiting at a certain time. The background when mismatched will always be red, which seems to have something to do with the fact that when you enter the Tower the game always sets the background to be red. I could get a quick repro setup going by starting in the checkpoint in Teleporter Divot, then quickly entering the Tower, exiting, then re-entering, then pressing Esc and quitting - all done very quickly. The important thing about this mismatch is that it's only temporary, and will be corrected when you press ACTION and the color of the text and background in the menu both change at the same time, which is what map.nexttowercolour() does. So all I do is simply call that function when exiting to the menu, and it will fix the color mismatch.
2020-01-23 02:20:32 +01:00
map.nexttowercolour();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
if (game.menupage == 20 && game.press_action)
{
//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
graphics.resumegamemode = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if (game.menupage == 21 && game.press_action)
{
//quit to menu
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
{
game.swnmode = 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
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.fadeout();
}
}
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;
}
}
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
void teleporterinput()
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;
}
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;
}
if (game.press_left)
{
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;
while (map.explored[tempx + (20 * tempy)] == 0)
{
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;
}
}
else if (game.press_right)
{
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;
while (map.explored[tempx + (20 * tempy)] == 0)
{
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;
}
}
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();
obj.entities[i].colour = 102;
i = obj.getteleporter();
obj.entities[i].tile = 6;
obj.entities[i].colour = 102;
//which teleporter script do we use? it depends on the companion!
game.state = 4000;
game.statedelay = 0;
}
}
}
}
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
void gamecompleteinput()
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;
if (key.isDown(KEYBOARD_z) || key.isDown(KEYBOARD_SPACE) || key.isDown(KEYBOARD_v) || key.isDown(game.controllerButton_flip))
{
game.creditposition -= 6;
Integrate dynamic list sizes for credited patrons, add CONTRIBUTORS to credits (Also added myself to the credits, only took 6 years to not be lazy about it)
2020-01-17 02:14:56 +01:00
if (game.creditposition <= -game.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
}
Integrate dynamic list sizes for credited patrons, add CONTRIBUTORS to credits (Also added myself to the credits, only took 6 years to not be lazy about it)
2020-01-17 02:14:56 +01:00
game.creditposition = -game.creditmaxposition;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
map.bypos += 6;
map.bscroll = +6;
}
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
}
}
}
}
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
void gamecompleteinput2()
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;
if (key.isDown(KEYBOARD_z) || key.isDown(KEYBOARD_SPACE) || key.isDown(KEYBOARD_v) || key.isDown(game.controllerButton_flip))
{
game.creditposx++;
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