2020-01-01 21:29:24 +01:00
|
|
|
#ifndef GAME_H
|
|
|
|
|
#define GAME_H
|
|
|
|
|
|
2020-07-19 06:21:27 +02:00
|
|
|
#include <SDL.h>
|
2020-07-19 21:43:29 +02:00
|
|
|
#include <string>
|
|
|
|
|
#include <vector>
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-11-13 01:45:51 +01:00
|
|
|
#include "ScreenSettings.h"
|
|
|
|
|
|
2020-09-14 01:31:02 +02:00
|
|
|
// Forward decl without including all of <tinyxml2.h>
|
Move all settings to settings.vvv
The game previously did this dumb thing where it lumped in all its
settings with its file that tracked your records and unlocks,
`unlock.vvv`. It wasn't really an issue, until 2.3 came along and added
a few settings, suddenly making a problem where 2.3 settings would be
reset by chance if you decided to touch 2.2.
The solution to this is to move all settings to a new file,
`settings.vvv`. However, for compatibility with 2.2, settings will still
be written to `unlock.vvv`.
The game will prioritize reading from `settings.vvv` instead of
`unlock.vvv`, so if there's a setting that's missing from `unlock.vvv`,
no worries there. But if `settings.vvv` is missing, then it'll read
settings from `unlock.vvv`. As well, if `unlock.vvv` is missing, then
`settings.vvv` will be read from instead (I explicitly tested for this,
and found that I had to write special code to handle this case,
otherwise the game would overwrite the existing `settings.vvv` before
reading from it; kids, make sure to always test your code!).
Closes #373 fully.
2020-11-04 08:11:21 +01:00
|
|
|
namespace tinyxml2
|
|
|
|
|
{
|
|
|
|
|
class XMLDocument;
|
|
|
|
|
class XMLElement;
|
|
|
|
|
}
|
2020-09-14 01:31:02 +02:00
|
|
|
|
2021-03-07 03:14:44 +01:00
|
|
|
/* 40 chars (160 bytes) covers the entire screen, + 1 more for null terminator */
|
|
|
|
|
#define MENU_TEXT_BYTES 161
|
|
|
|
|
|
2020-04-15 06:11:10 +02:00
|
|
|
struct MenuOption
|
|
|
|
|
{
|
2021-03-07 03:14:44 +01:00
|
|
|
char text[MENU_TEXT_BYTES];
|
2020-04-15 06:11:10 +02:00
|
|
|
bool active;
|
|
|
|
|
};
|
|
|
|
|
|
2020-04-16 06:53:36 +02:00
|
|
|
//Menu IDs
|
|
|
|
|
namespace Menu
|
|
|
|
|
{
|
|
|
|
|
enum MenuName
|
|
|
|
|
{
|
|
|
|
|
mainmenu,
|
|
|
|
|
playerworlds,
|
|
|
|
|
levellist,
|
|
|
|
|
quickloadlevel,
|
|
|
|
|
youwannaquit,
|
|
|
|
|
errornostart,
|
2020-11-22 03:10:26 +01:00
|
|
|
errorsavingsettings,
|
2020-04-16 06:53:36 +02:00
|
|
|
graphicoptions,
|
|
|
|
|
ed_settings,
|
|
|
|
|
ed_desc,
|
|
|
|
|
ed_music,
|
|
|
|
|
ed_quit,
|
|
|
|
|
options,
|
2020-06-30 22:06:19 +02:00
|
|
|
advancedoptions,
|
2020-04-16 06:53:36 +02:00
|
|
|
accessibility,
|
|
|
|
|
controller,
|
|
|
|
|
cleardatamenu,
|
|
|
|
|
setinvincibility,
|
2020-04-17 01:02:01 +02:00
|
|
|
setslowdown,
|
2020-04-16 06:53:36 +02:00
|
|
|
unlockmenu,
|
|
|
|
|
credits,
|
|
|
|
|
credits2,
|
|
|
|
|
credits25,
|
|
|
|
|
credits3,
|
|
|
|
|
credits4,
|
|
|
|
|
credits5,
|
|
|
|
|
credits6,
|
|
|
|
|
play,
|
|
|
|
|
unlocktimetrial,
|
|
|
|
|
unlocktimetrials,
|
|
|
|
|
unlocknodeathmode,
|
|
|
|
|
unlockintermission,
|
|
|
|
|
unlockflipmode,
|
|
|
|
|
newgamewarning,
|
|
|
|
|
playmodes,
|
|
|
|
|
intermissionmenu,
|
|
|
|
|
playint1,
|
|
|
|
|
playint2,
|
|
|
|
|
continuemenu,
|
|
|
|
|
startnodeathmode,
|
|
|
|
|
gameover,
|
|
|
|
|
gameover2,
|
|
|
|
|
unlockmenutrials,
|
|
|
|
|
timetrials,
|
|
|
|
|
nodeathmodecomplete,
|
|
|
|
|
nodeathmodecomplete2,
|
|
|
|
|
timetrialcomplete,
|
|
|
|
|
timetrialcomplete2,
|
|
|
|
|
timetrialcomplete3,
|
|
|
|
|
gamecompletecontinue,
|
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
|
2020-04-17 01:22:40 +02:00
|
|
|
struct MenuStackFrame
|
|
|
|
|
{
|
|
|
|
|
int option;
|
|
|
|
|
enum Menu::MenuName name;
|
|
|
|
|
};
|
|
|
|
|
|
Refactor how custom level stats are stored, read, and written
There were a few problems with the old way of doing things:
(1) Level stats were an ad-hoc object. Basically, it's an object whose
attributes are stored in separate arrays, instead of being an actual
object with its attributes stored in one array.
(2) Level filenames with pipes in them could cause trouble. This is
because the filename attribute array was stored in the XML by being
separated by pipes.
(3) There was an arbitrary limit of only having 200 level stats, for
whatever reason.
To remedy this issue, I've made a new struct named CustomLevelStat that
is a proper object. The separate attribute arrays have been replaced
with a proper vector, which also doesn't have a size limit.
For compatibility with versions 2.2 and below, I've kept being able to
read the old format. This only happens if the new format doesn't exist.
However, I also WRITE the old format as well, in case you want to go
back to version 2.2 or below for whatever reason. It's slightly
wasteful to have both, but that way there's no risk of breaking
compatibility.
2020-06-30 03:39:22 +02:00
|
|
|
struct CustomLevelStat
|
|
|
|
|
{
|
|
|
|
|
std::string name;
|
|
|
|
|
int score; //0 - not played, 1 - finished, 2 - all trinkets, 3 - finished, all trinkets
|
|
|
|
|
};
|
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
class Game
|
|
|
|
|
{
|
|
|
|
|
public:
|
Allow using help/graphics/music/game/key/map/obj everywhere
This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and
`obj` essentially static global objects that can be used everywhere.
This is useful in case we ever need to add a new function in the future,
so we don't have to bother with passing a new argument in which means we
have to pass a new argument in to the function that calls that function
which means having to pass a new argument into the function that calls
THAT function, etc. which is a real headache when working on fan mods of
the source code.
Note that this changes NONE of the existing function signatures, it
merely just makes those variables accessible everywhere in the same way
`script` and `ed` are.
Also note that some classes had to be initialized after the filesystem
was initialized, but C++ would keep initializing them before the
filesystem got initialized, because I *had* to put them at the top of
`main.cpp`, or else they wouldn't be global variables.
The only way to work around this was to use entityclass's initialization
style (which I'm pretty sure entityclass of all things doesn't need to
be initialized this way), where you actually initialize the class in an
`init()` function, and so then you do `graphics.init()` after the
filesystem initialization, AFTER doing `Graphics graphics` up at the
top.
I've had to do this for `graphics` (but only because its child
GraphicsResources `grphx` needs to be initialized this way), `music`,
and `game`. I don't think this will affect anything. Other than that,
`help`, `key`, and `map` are still using the C++-intended method of
having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
|
|
|
void init(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
int crewrescued(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
std::string unrescued(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void resetgameclock(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-11-04 03:45:33 +01:00
|
|
|
bool customsavequick(std::string savfile);
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
bool savequick(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void gameclock(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-03-31 02:16:02 +02:00
|
|
|
std::string giventimestring(int hrs, int min, int sec);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
std::string timestring(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
std::string partimestring(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
std::string resulttimestring(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-03-31 02:16:02 +02:00
|
|
|
std::string timetstring(int t);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void returnmenu(void);
|
2020-04-26 02:36:36 +02:00
|
|
|
void returntomenu(enum Menu::MenuName t);
|
2020-04-17 04:04:36 +02:00
|
|
|
void createmenu(enum Menu::MenuName t, bool samemenu = false);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void lifesequence(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void gethardestroom(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2021-03-20 03:37:54 +01:00
|
|
|
void levelcomplete_textbox(void);
|
|
|
|
|
void crewmate_textbox(const int r, const int g, const int b);
|
|
|
|
|
void remaining_textbox(void);
|
|
|
|
|
void actionprompt_textbox(void);
|
2021-03-20 03:40:16 +01:00
|
|
|
void savetele_textbox(void);
|
2021-03-20 03:37:54 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void updatestate(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-03-31 02:16:02 +02:00
|
|
|
void unlocknum(int t);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-11-13 01:45:51 +01:00
|
|
|
void loadstats(ScreenSettings* screen_settings);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-12-22 01:34:16 +01:00
|
|
|
bool savestats(const ScreenSettings* screen_settings);
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
bool savestats(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void deletestats(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-11-13 01:45:51 +01:00
|
|
|
void deserializesettings(tinyxml2::XMLElement* dataNode, ScreenSettings* screen_settings);
|
Move all settings to settings.vvv
The game previously did this dumb thing where it lumped in all its
settings with its file that tracked your records and unlocks,
`unlock.vvv`. It wasn't really an issue, until 2.3 came along and added
a few settings, suddenly making a problem where 2.3 settings would be
reset by chance if you decided to touch 2.2.
The solution to this is to move all settings to a new file,
`settings.vvv`. However, for compatibility with 2.2, settings will still
be written to `unlock.vvv`.
The game will prioritize reading from `settings.vvv` instead of
`unlock.vvv`, so if there's a setting that's missing from `unlock.vvv`,
no worries there. But if `settings.vvv` is missing, then it'll read
settings from `unlock.vvv`. As well, if `unlock.vvv` is missing, then
`settings.vvv` will be read from instead (I explicitly tested for this,
and found that I had to write special code to handle this case,
otherwise the game would overwrite the existing `settings.vvv` before
reading from it; kids, make sure to always test your code!).
Closes #373 fully.
2020-11-04 08:11:21 +01:00
|
|
|
|
2020-12-22 01:34:16 +01:00
|
|
|
void serializesettings(tinyxml2::XMLElement* dataNode, const ScreenSettings* screen_settings);
|
Move all settings to settings.vvv
The game previously did this dumb thing where it lumped in all its
settings with its file that tracked your records and unlocks,
`unlock.vvv`. It wasn't really an issue, until 2.3 came along and added
a few settings, suddenly making a problem where 2.3 settings would be
reset by chance if you decided to touch 2.2.
The solution to this is to move all settings to a new file,
`settings.vvv`. However, for compatibility with 2.2, settings will still
be written to `unlock.vvv`.
The game will prioritize reading from `settings.vvv` instead of
`unlock.vvv`, so if there's a setting that's missing from `unlock.vvv`,
no worries there. But if `settings.vvv` is missing, then it'll read
settings from `unlock.vvv`. As well, if `unlock.vvv` is missing, then
`settings.vvv` will be read from instead (I explicitly tested for this,
and found that I had to write special code to handle this case,
otherwise the game would overwrite the existing `settings.vvv` before
reading from it; kids, make sure to always test your code!).
Closes #373 fully.
2020-11-04 08:11:21 +01:00
|
|
|
|
2020-11-13 01:45:51 +01:00
|
|
|
void loadsettings(ScreenSettings* screen_settings);
|
Move all settings to settings.vvv
The game previously did this dumb thing where it lumped in all its
settings with its file that tracked your records and unlocks,
`unlock.vvv`. It wasn't really an issue, until 2.3 came along and added
a few settings, suddenly making a problem where 2.3 settings would be
reset by chance if you decided to touch 2.2.
The solution to this is to move all settings to a new file,
`settings.vvv`. However, for compatibility with 2.2, settings will still
be written to `unlock.vvv`.
The game will prioritize reading from `settings.vvv` instead of
`unlock.vvv`, so if there's a setting that's missing from `unlock.vvv`,
no worries there. But if `settings.vvv` is missing, then it'll read
settings from `unlock.vvv`. As well, if `unlock.vvv` is missing, then
`settings.vvv` will be read from instead (I explicitly tested for this,
and found that I had to write special code to handle this case,
otherwise the game would overwrite the existing `settings.vvv` before
reading from it; kids, make sure to always test your code!).
Closes #373 fully.
2020-11-04 08:11:21 +01:00
|
|
|
|
2020-12-22 01:34:16 +01:00
|
|
|
bool savesettings(const ScreenSettings* screen_settings);
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
bool savesettings(void);
|
Move all settings to settings.vvv
The game previously did this dumb thing where it lumped in all its
settings with its file that tracked your records and unlocks,
`unlock.vvv`. It wasn't really an issue, until 2.3 came along and added
a few settings, suddenly making a problem where 2.3 settings would be
reset by chance if you decided to touch 2.2.
The solution to this is to move all settings to a new file,
`settings.vvv`. However, for compatibility with 2.2, settings will still
be written to `unlock.vvv`.
The game will prioritize reading from `settings.vvv` instead of
`unlock.vvv`, so if there's a setting that's missing from `unlock.vvv`,
no worries there. But if `settings.vvv` is missing, then it'll read
settings from `unlock.vvv`. As well, if `unlock.vvv` is missing, then
`settings.vvv` will be read from instead (I explicitly tested for this,
and found that I had to write special code to handle this case,
otherwise the game would overwrite the existing `settings.vvv` before
reading from it; kids, make sure to always test your code!).
Closes #373 fully.
2020-11-04 08:11:21 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
bool savestatsandsettings(void);
|
Refactor Game::savestats() to not use a default argument
In order to be able to fix the bug #556, I'm planning on adding
ScreenSettings* to the settings.vvv write function. However, that
entails adding another argument to Game::savesettings(), which is going
to be really messy given the default argument of Game::savestats().
That, combined with the fact that the code comment at the site of the
implementation of Game::savestats() being wrong (!!!), leads me to
believe that using default function arguments here isn't worth it.
Instead, what I've done is made it so callers are explicit about whether
or not they're calling savestats(), savesettings(), or both at the same
time. If they are calling both at the same time, then they will be using
a new function named savestatsandsettings().
In short, these are the interface changes:
* bool Game::savestats(bool) has been removed
* bool Game::savestatsandsettings() has been added
* void Game::savestats_menu() has been renamed to
void Game::savestatsandsettings_menu()
* All previous callers of bool Game::savestats() are now using bool
Game::savestatsandsettings()
* The one caller of bool Game::savestats(bool) is now using bool
Game::savestats()
2020-12-22 01:03:19 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void savestatsandsettings_menu(void);
|
Refactor Game::savestats() to not use a default argument
In order to be able to fix the bug #556, I'm planning on adding
ScreenSettings* to the settings.vvv write function. However, that
entails adding another argument to Game::savesettings(), which is going
to be really messy given the default argument of Game::savestats().
That, combined with the fact that the code comment at the site of the
implementation of Game::savestats() being wrong (!!!), leads me to
believe that using default function arguments here isn't worth it.
Instead, what I've done is made it so callers are explicit about whether
or not they're calling savestats(), savesettings(), or both at the same
time. If they are calling both at the same time, then they will be using
a new function named savestatsandsettings().
In short, these are the interface changes:
* bool Game::savestats(bool) has been removed
* bool Game::savestatsandsettings() has been added
* void Game::savestats_menu() has been renamed to
void Game::savestatsandsettings_menu()
* All previous callers of bool Game::savestats() are now using bool
Game::savestatsandsettings()
* The one caller of bool Game::savestats(bool) is now using bool
Game::savestats()
2020-12-22 01:03:19 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void deletesettings(void);
|
Move all settings to settings.vvv
The game previously did this dumb thing where it lumped in all its
settings with its file that tracked your records and unlocks,
`unlock.vvv`. It wasn't really an issue, until 2.3 came along and added
a few settings, suddenly making a problem where 2.3 settings would be
reset by chance if you decided to touch 2.2.
The solution to this is to move all settings to a new file,
`settings.vvv`. However, for compatibility with 2.2, settings will still
be written to `unlock.vvv`.
The game will prioritize reading from `settings.vvv` instead of
`unlock.vvv`, so if there's a setting that's missing from `unlock.vvv`,
no worries there. But if `settings.vvv` is missing, then it'll read
settings from `unlock.vvv`. As well, if `unlock.vvv` is missing, then
`settings.vvv` will be read from instead (I explicitly tested for this,
and found that I had to write special code to handle this case,
otherwise the game would overwrite the existing `settings.vvv` before
reading from it; kids, make sure to always test your code!).
Closes #373 fully.
2020-11-04 08:11:21 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void deletequick(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
bool savetele(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void loadtele(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void deletetele(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void customstart(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void start(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-03-31 02:16:02 +02:00
|
|
|
void startspecial(int t);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-03-31 02:16:02 +02:00
|
|
|
void starttrial(int t);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void swnpenalty(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void deathsequence(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-03-31 02:16:02 +02:00
|
|
|
void customloadquick(std::string savfile);
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void loadquick(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void loadsummary(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-09-14 01:31:02 +02:00
|
|
|
void readmaingamesave(tinyxml2::XMLDocument& doc);
|
|
|
|
|
std::string writemaingamesave(tinyxml2::XMLDocument& doc);
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void initteleportermode(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2021-03-07 00:30:22 +01:00
|
|
|
const char* saveFilePath;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
int door_left;
|
|
|
|
|
int door_right;
|
|
|
|
|
int door_up;
|
|
|
|
|
int door_down;
|
|
|
|
|
int roomx, roomy, roomchangedir;
|
2020-01-27 23:46:11 +01:00
|
|
|
int prevroomx, prevroomy;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
int savex, savey, saverx, savery;
|
|
|
|
|
int savegc, savedir;
|
|
|
|
|
|
|
|
|
|
//Added for port
|
|
|
|
|
int edsavex, edsavey, edsaverx, edsavery;
|
|
|
|
|
int edsavegc, edsavedir;
|
|
|
|
|
|
|
|
|
|
//State logic stuff
|
|
|
|
|
int state, statedelay;
|
|
|
|
|
|
2020-04-02 22:01:55 +02:00
|
|
|
bool glitchrunkludge;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
int gamestate;
|
Fix bringing up map menu during gamemode(teleporter)
When gamemode(teleporter) gets run in a script, it brings up a read-only
version of the teleporter screen, intended only for displaying rooms on
the minimap.
However, ever since 2.3 allowed bringing up the map screen during
cutscenes (in order to prevent softlocks), bringing up the map screen
during this mode would (1) do an unnecessary animation of suddenly
switching back to the game and bringing up the menu screen again (even
though the menu screen has already been brought up), and (2) would let
you close the menu entirely and go back to GAMEMODE, thus
unintentionally closing the teleporter screen and kind of ruining the
cutscene.
To fix this, when you bring up the map screen, it will instead instantly
transition to the map screen. And when you bring it down, it will also
instantly transition back to the teleporter screen.
But that's not all. The previous behavior was actually kind of a nice
failsafe, in that if you somehow got stuck in a state where a script ran
gamemode(teleporter), but stopped running before it could take you out
of that mode by running gamemode(game), then you could return to
GAMEMODE yourself by bringing up the map screen and then bringing it
back down. So I've made sure to keep that failsafe behavior, only as
long as there isn't a script running.
2020-12-29 00:36:32 +01:00
|
|
|
int prevgamestate; //only used sometimes
|
2020-01-01 21:29:24 +01:00
|
|
|
bool hascontrol, jumpheld;
|
|
|
|
|
int jumppressed;
|
|
|
|
|
int gravitycontrol;
|
|
|
|
|
|
|
|
|
|
bool muted;
|
|
|
|
|
int mutebutton;
|
2020-04-19 21:40:59 +02:00
|
|
|
bool musicmuted;
|
|
|
|
|
int musicmutebutton;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
int tapleft, tapright;
|
|
|
|
|
|
|
|
|
|
//Menu interaction stuff
|
De-duplicate menu animation code when bringing up map screen
When bringing up the map screen, the game does a small menu animation
where the menu comes in from the bottom. The code to calculate the menu
offset is copy-pasted everywhere, so I thought I'd de-duplicate it to
make my life easier when working with it. I also included the
game.gamestate assignment in the de-duplicated function, so it would be
easier for a future bugfix.
At the same time, I'm also removing all the BlitSurfaceStandard()s that
copied menubuffer to backBuffer. The red flag is that this blit happened
for every single entry point to MAPMODE and TELEPORTERMODE, except for
the script command gamemode(teleporter). Pressing Enter to bring up the
map screen, pressing Enter to quit the Super Gravitron, pressing Esc to
bring up the pause screen, and pressing Enter to bring up the teleporter
screen all do this blit, so if this blit was there to fix a bug, then
there's a bug with using the script command gamemode(teleporter)... but,
as far as I can tell, there isn't.
That's because the blit basically does nothing. All the blit does is
copy menubuffer onto backBuffer. Then the next thing that happens is
that either maprender() or teleporterrender() will be called, and the
first thing that those functions will always do is fill backBuffer with
solid black, completely overriding the previous blit. So that's why
removing this blit won't have any effect, and it can be safely removed
for code clarity.
2020-12-28 23:23:35 +01:00
|
|
|
void mapmenuchange(const int newgamestate);
|
2020-01-01 21:29:24 +01:00
|
|
|
bool mapheld;
|
|
|
|
|
int menupage;
|
|
|
|
|
int lastsaved;
|
|
|
|
|
int deathcounts;
|
|
|
|
|
|
|
|
|
|
int frames, seconds, minutes, hours;
|
|
|
|
|
bool gamesaved;
|
2020-11-04 03:45:33 +01:00
|
|
|
bool gamesavefailed;
|
2020-01-01 21:29:24 +01:00
|
|
|
std::string savetime;
|
|
|
|
|
std::string savearea;
|
|
|
|
|
int savetrinkets;
|
|
|
|
|
bool startscript;
|
|
|
|
|
std::string newscript;
|
|
|
|
|
|
|
|
|
|
int mainmenu;
|
|
|
|
|
bool menustart;
|
|
|
|
|
|
|
|
|
|
//Teleporting
|
|
|
|
|
bool teleport_to_new_area;
|
|
|
|
|
int teleport_to_x, teleport_to_y;
|
|
|
|
|
std::string teleportscript;
|
|
|
|
|
bool useteleporter;
|
|
|
|
|
int teleport_to_teleporter;
|
|
|
|
|
|
|
|
|
|
//Main Menu Variables
|
Refactor menu creation code
Firstly, menu options are no longer ad-hoc objects, and are added by
using Game::option() (this is the biggest change). This removes the
vector Game::menuoptionsactive, and Game::menuoptions is now a vector of
MenuOption instead of std::string.
Secondly, the manual tracker variable of the amount of menu options,
Game::nummenuoptions, has been removed, in favor of using vectors
properly and using Game::menuoptions::size().
As a result, a lot of copy-pasted code has been removed from
Game::createmenu(), mostly due to having to have different versions of
menus depending on whether or not we have certain defines, or having an
mmmmmm.vvv file inside the VVVVVV directory. In the old days, you
couldn't just add or remove a menu option conveniently, you had to
shuffle around the position of every other menu option too, which
resulted in lots of copy-pasted code. But now this copy-pasted code has
been de-duplicated, at least in Game::createmenu().
2020-04-15 06:50:17 +02:00
|
|
|
std::vector<MenuOption> menuoptions;
|
|
|
|
|
int currentmenuoption ;
|
2020-04-17 05:09:22 +02:00
|
|
|
enum Menu::MenuName currentmenuname;
|
2020-06-23 02:23:56 +02:00
|
|
|
enum Menu::MenuName kludge_ingametemp;
|
2020-02-12 05:45:58 +01:00
|
|
|
int current_credits_list_index;
|
2020-01-01 21:29:24 +01:00
|
|
|
int menuxoff, menuyoff;
|
Make menus automatically centered and narrowed
All menus had a hardcoded X position (offset to an arbitrary starting
point of 110) and a hardcoded horizontal spacing for the "staircasing"
(mostly 30 pixels, but for some specific menus hardcoded to 15, 20 or
something else). Not all menus were centered, and seem to have been
manually made narrower (with lower horizontal spacing) whenever text
ran offscreen during development.
This system may already be hard to work with in an English-only menu
system, since you may need to adjust horizontal spacing or positioning
when adding an option. The main reason I made this change is that it's
even less optimal when menu options have to be translated, since
maximum string lengths are hard to determine, and it's easy to have
menu options running offscreen, especially when not all menus are
checked for all languages and when options could be added in the middle
of a menu after translations of that menu are already checked.
Now, menus are automatically centered based on their options, and they
are automatically made narrower if they won't fit with the default
horizontal spacing of 30 pixels (with some padding). The game.menuxoff
variable for the menu X position is now also offset to 0 instead of 110
The _default_ horizontal spacing can be changed on a per-menu basis,
and most menus (not all) which already had a narrower spacing set,
retain that as a maximum spacing, simply because they looked odd with
30 pixels of spacing (especially the main menu). They will be made even
narrower automatically if needed. In the most extreme case, the spacing
can go down to 0 and options will be displayed right below each other.
This isn't in the usual style of the game, but at least we did the best
we could to prevent options running offscreen.
The only exception to automatic menu centering and narrowing is the
list of player levels, because it's a special case and existing
behavior would be better than automatic centering there.
2020-06-29 02:09:52 +02:00
|
|
|
int menuspacing;
|
2020-04-17 03:52:40 +02:00
|
|
|
std::vector<MenuStackFrame> menustack;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-07-04 06:30:31 +02:00
|
|
|
void inline option(const char* text, bool active = true)
|
2020-04-15 06:12:24 +02:00
|
|
|
{
|
|
|
|
|
MenuOption menuoption;
|
2020-07-04 06:30:31 +02:00
|
|
|
SDL_strlcpy(menuoption.text, text, sizeof(menuoption.text));
|
2020-04-15 06:12:24 +02:00
|
|
|
menuoption.active = active;
|
|
|
|
|
menuoptions.push_back(menuoption);
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
int menucountdown;
|
2020-04-16 06:53:36 +02:00
|
|
|
enum Menu::MenuName menudest;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
int creditposx, creditposy, creditposdelay;
|
2020-05-02 03:23:52 +02:00
|
|
|
int oldcreditposx;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-11-22 03:10:26 +01:00
|
|
|
bool silence_settings_error;
|
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
//Sine Wave Ninja Minigame
|
|
|
|
|
bool swnmode;
|
|
|
|
|
int swngame, swnstate, swnstate2, swnstate3, swnstate4, swndelay, swndeaths;
|
|
|
|
|
int swntimer, swncolstate, swncoldelay;
|
|
|
|
|
int swnrecord, swnbestrank, swnrank, swnmessage;
|
|
|
|
|
|
|
|
|
|
//SuperCrewMate Stuff
|
|
|
|
|
bool supercrewmate, scmhurt, scmmoveme;
|
|
|
|
|
int scmprogress;
|
|
|
|
|
|
|
|
|
|
//Accessibility Options
|
|
|
|
|
bool colourblindmode;
|
|
|
|
|
bool noflashingmode;
|
|
|
|
|
int slowdown;
|
|
|
|
|
|
|
|
|
|
bool nodeathmode;
|
|
|
|
|
int gameoverdelay;
|
|
|
|
|
bool nocutscenes;
|
2021-01-08 01:18:07 +01:00
|
|
|
int ndmresultcrewrescued;
|
|
|
|
|
int ndmresulttrinkets;
|
|
|
|
|
std::string ndmresulthardestroom;
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void copyndmresults(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
//Time Trials
|
|
|
|
|
bool intimetrial, timetrialparlost;
|
|
|
|
|
int timetrialcountdown, timetrialshinytarget, timetriallevel;
|
2020-06-30 00:53:19 +02:00
|
|
|
int timetrialpar, timetrialresulttime, timetrialresultframes, timetrialrank;
|
2021-01-08 01:02:45 +01:00
|
|
|
int timetrialresultshinytarget, timetrialresulttrinkets, timetrialresultpar;
|
|
|
|
|
int timetrialresultdeaths;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
int creditposition;
|
2020-04-30 19:56:27 +02:00
|
|
|
int oldcreditposition;
|
2020-01-01 21:29:24 +01:00
|
|
|
bool insecretlab;
|
|
|
|
|
|
|
|
|
|
bool inintermission;
|
|
|
|
|
|
2020-07-03 03:10:52 +02:00
|
|
|
static const int numcrew = 6;
|
|
|
|
|
bool crewstats[numcrew];
|
2021-01-08 01:18:07 +01:00
|
|
|
bool ndmresultcrewstats[numcrew];
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
bool alarmon;
|
|
|
|
|
int alarmdelay;
|
|
|
|
|
bool blackout;
|
|
|
|
|
|
2020-07-03 03:10:52 +02:00
|
|
|
bool tele_crewstats[numcrew];
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-07-03 03:10:52 +02:00
|
|
|
bool quick_crewstats[numcrew];
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-07-03 01:45:22 +02:00
|
|
|
static const int numunlock = 25;
|
|
|
|
|
bool unlock[numunlock];
|
|
|
|
|
bool unlocknotify[numunlock];
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
bool anything_unlocked(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
int stat_trinkets;
|
|
|
|
|
int bestgamedeaths;
|
|
|
|
|
|
|
|
|
|
|
2020-07-03 02:09:30 +02:00
|
|
|
static const int numtrials = 6;
|
|
|
|
|
int besttimes[numtrials];
|
|
|
|
|
int bestframes[numtrials];
|
|
|
|
|
int besttrinkets[numtrials];
|
|
|
|
|
int bestlives[numtrials];
|
|
|
|
|
int bestrank[numtrials];
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
std::string tele_gametime;
|
|
|
|
|
int tele_trinkets;
|
|
|
|
|
std::string tele_currentarea;
|
|
|
|
|
std::string quick_gametime;
|
|
|
|
|
int quick_trinkets;
|
|
|
|
|
std::string quick_currentarea;
|
|
|
|
|
|
|
|
|
|
int mx, my;
|
|
|
|
|
int screenshake, flashlight;
|
|
|
|
|
bool advancetext, pausescript;
|
|
|
|
|
|
|
|
|
|
int deathseq, lifeseq;
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
int trinkets(void);
|
|
|
|
|
int crewmates(void);
|
2020-04-09 07:27:13 +02:00
|
|
|
int savepoint, teleportxpos;
|
|
|
|
|
bool teleport;
|
2020-01-01 21:29:24 +01:00
|
|
|
int edteleportent;
|
|
|
|
|
bool completestop;
|
|
|
|
|
|
|
|
|
|
float inertia;
|
|
|
|
|
|
|
|
|
|
int companion;
|
|
|
|
|
bool roomchange;
|
|
|
|
|
SDL_Rect teleblock;
|
|
|
|
|
bool activetele;
|
|
|
|
|
int readytotele;
|
2020-04-30 02:04:25 +02:00
|
|
|
int oldreadytotele;
|
2020-01-01 21:29:24 +01:00
|
|
|
int activity_r, activity_g, activity_b;
|
|
|
|
|
std::string activity_lastprompt;
|
|
|
|
|
|
|
|
|
|
std::string telesummary, quicksummary, customquicksummary;
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
bool save_exists(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
bool backgroundtext;
|
|
|
|
|
|
|
|
|
|
int activeactivity, act_fade;
|
2020-04-29 06:58:19 +02:00
|
|
|
int prev_act_fade;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
bool press_left, press_right, press_action, press_map;
|
|
|
|
|
|
|
|
|
|
//Some stats:
|
|
|
|
|
int totalflips;
|
|
|
|
|
std::string hardestroom;
|
|
|
|
|
int hardestroomdeaths, currentroomdeaths;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bool quickrestartkludge;
|
|
|
|
|
|
|
|
|
|
//Custom stuff
|
|
|
|
|
std::string customscript[50];
|
|
|
|
|
int customcol;
|
|
|
|
|
int levelpage;
|
|
|
|
|
int playcustomlevel;
|
|
|
|
|
std::string customleveltitle;
|
|
|
|
|
std::string customlevelfilename;
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void clearcustomlevelstats(void);
|
|
|
|
|
void loadcustomlevelstats(void);
|
|
|
|
|
void savecustomlevelstats(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
void updatecustomlevelstats(std::string clevel, int cscore);
|
|
|
|
|
|
Refactor how custom level stats are stored, read, and written
There were a few problems with the old way of doing things:
(1) Level stats were an ad-hoc object. Basically, it's an object whose
attributes are stored in separate arrays, instead of being an actual
object with its attributes stored in one array.
(2) Level filenames with pipes in them could cause trouble. This is
because the filename attribute array was stored in the XML by being
separated by pipes.
(3) There was an arbitrary limit of only having 200 level stats, for
whatever reason.
To remedy this issue, I've made a new struct named CustomLevelStat that
is a proper object. The separate attribute arrays have been replaced
with a proper vector, which also doesn't have a size limit.
For compatibility with versions 2.2 and below, I've kept being able to
read the old format. This only happens if the new format doesn't exist.
However, I also WRITE the old format as well, in case you want to go
back to version 2.2 or below for whatever reason. It's slightly
wasteful to have both, but that way there's no risk of breaking
compatibility.
2020-06-30 03:39:22 +02:00
|
|
|
std::vector<CustomLevelStat> customlevelstats;
|
2020-01-01 21:29:24 +01:00
|
|
|
bool customlevelstatsloaded;
|
|
|
|
|
|
|
|
|
|
|
2020-04-02 22:01:55 +02:00
|
|
|
std::vector<SDL_GameControllerButton> controllerButton_map;
|
|
|
|
|
std::vector<SDL_GameControllerButton> controllerButton_flip;
|
|
|
|
|
std::vector<SDL_GameControllerButton> controllerButton_esc;
|
2020-08-09 00:41:59 +02:00
|
|
|
std::vector<SDL_GameControllerButton> controllerButton_restart;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-01-13 02:45:44 +01:00
|
|
|
bool skipfakeload;
|
Add a player trail to the editor (ghosts)
A few months ago, I added ghosts to the VVVVVV: Community Edition editor. I was told recently I should think
about upstreaming it, and with Terry saying go ahead I finally ported them into VVVVVV. There's one slight
difference however--you can choose whether you have them or not in the editor's settings menu. They're off by
default, and this is saved to the save file.
Anyway, when you're playtesting, the game saves the players position, color, room coordinates and sprite every 3
frames. The max is 100, where if it tries to add more, the oldest one gets removed.
When you exit playtesting, the saved positions appear one at a time, and you can use the Z key to speed it up.
[Here's a video of them in action.](https://o.lol-sa.me/4H21zCv.mp4)
2020-06-13 00:04:35 +02:00
|
|
|
bool ghostsenabled;
|
2020-04-09 21:03:24 +02:00
|
|
|
|
|
|
|
|
bool cliplaytest;
|
|
|
|
|
int playx;
|
|
|
|
|
int playy;
|
|
|
|
|
int playrx;
|
|
|
|
|
int playry;
|
|
|
|
|
int playgc;
|
2020-07-11 20:55:26 +02:00
|
|
|
int playmusic;
|
2020-06-22 00:56:31 +02:00
|
|
|
std::string playassets;
|
2020-05-07 23:38:19 +02:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void quittomenu(void);
|
|
|
|
|
void returntolab(void);
|
2020-05-08 00:23:55 +02:00
|
|
|
bool fadetomenu;
|
|
|
|
|
int fadetomenudelay;
|
2020-05-08 00:30:26 +02:00
|
|
|
bool fadetolab;
|
|
|
|
|
int fadetolabdelay;
|
2020-05-09 21:35:17 +02:00
|
|
|
|
|
|
|
|
#if !defined(NO_CUSTOM_LEVELS)
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void returntoeditor(void);
|
2020-05-09 21:35:17 +02:00
|
|
|
#endif
|
Add a player trail to the editor (ghosts)
A few months ago, I added ghosts to the VVVVVV: Community Edition editor. I was told recently I should think
about upstreaming it, and with Terry saying go ahead I finally ported them into VVVVVV. There's one slight
difference however--you can choose whether you have them or not in the editor's settings menu. They're off by
default, and this is saved to the save file.
Anyway, when you're playtesting, the game saves the players position, color, room coordinates and sprite every 3
frames. The max is 100, where if it tries to add more, the oldest one gets removed.
When you exit playtesting, the saved positions appear one at a time, and you can use the Z key to speed it up.
[Here's a video of them in action.](https://o.lol-sa.me/4H21zCv.mp4)
2020-06-13 00:04:35 +02:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
bool inline inspecial(void)
|
2020-06-14 05:07:52 +02:00
|
|
|
{
|
|
|
|
|
return inintermission || insecretlab || intimetrial || nodeathmode;
|
|
|
|
|
}
|
2020-05-04 21:52:57 +02:00
|
|
|
|
|
|
|
|
bool over30mode;
|
2020-06-25 23:31:37 +02:00
|
|
|
bool glitchrunnermode; // Have fun speedrunners! <3 Misa
|
2020-06-23 01:51:16 +02:00
|
|
|
|
|
|
|
|
bool ingame_titlemode;
|
Add graphic options and game options to editor settings
This is a small quality-of-life tweak that makes it so if you're in the
middle of editing a level, you don't have to save the level, exit to the
menu, change whatever setting you wanted, re-enter the editor, and type
in the level name, just to change one setting. This is the same as
adding Graphic Options and Game Options to the in-game pause menu,
except for the editor, too.
To do this, I'm reusing Game::returntopausemenu() (because all of its
callers are the same callers for returning to editor settings) and
renamed it to returntoingame(), then added a variable named
ingame_editormode to Game. When we're in the options menus but still in
the editor, BOTH ingame_titlemode and ingame_editormode will be true.
2021-03-19 03:52:30 +01:00
|
|
|
#if !defined(NO_CUSTOM_LEVELS) && !defined(NO_EDITOR)
|
|
|
|
|
bool ingame_editormode;
|
|
|
|
|
#endif
|
2020-06-23 02:26:45 +02:00
|
|
|
|
Add graphic options and game options to editor settings
This is a small quality-of-life tweak that makes it so if you're in the
middle of editing a level, you don't have to save the level, exit to the
menu, change whatever setting you wanted, re-enter the editor, and type
in the level name, just to change one setting. This is the same as
adding Graphic Options and Game Options to the in-game pause menu,
except for the editor, too.
To do this, I'm reusing Game::returntopausemenu() (because all of its
callers are the same callers for returning to editor settings) and
renamed it to returntoingame(), then added a variable named
ingame_editormode to Game. When we're in the options menus but still in
the editor, BOTH ingame_titlemode and ingame_editormode will be true.
2021-03-19 03:52:30 +01:00
|
|
|
void returntoingame(void);
|
2020-08-01 21:51:11 +02:00
|
|
|
void unlockAchievement(const char *name);
|
2020-06-30 04:49:14 +02:00
|
|
|
|
|
|
|
|
bool disablepause;
|
2020-01-01 21:29:24 +01:00
|
|
|
};
|
|
|
|
|
|
2020-09-28 04:15:06 +02:00
|
|
|
#ifndef GAME_DEFINITION
|
Allow using help/graphics/music/game/key/map/obj everywhere
This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and
`obj` essentially static global objects that can be used everywhere.
This is useful in case we ever need to add a new function in the future,
so we don't have to bother with passing a new argument in which means we
have to pass a new argument in to the function that calls that function
which means having to pass a new argument into the function that calls
THAT function, etc. which is a real headache when working on fan mods of
the source code.
Note that this changes NONE of the existing function signatures, it
merely just makes those variables accessible everywhere in the same way
`script` and `ed` are.
Also note that some classes had to be initialized after the filesystem
was initialized, but C++ would keep initializing them before the
filesystem got initialized, because I *had* to put them at the top of
`main.cpp`, or else they wouldn't be global variables.
The only way to work around this was to use entityclass's initialization
style (which I'm pretty sure entityclass of all things doesn't need to
be initialized this way), where you actually initialize the class in an
`init()` function, and so then you do `graphics.init()` after the
filesystem initialization, AFTER doing `Graphics graphics` up at the
top.
I've had to do this for `graphics` (but only because its child
GraphicsResources `grphx` needs to be initialized this way), `music`,
and `game`. I don't think this will affect anything. Other than that,
`help`, `key`, and `map` are still using the C++-intended method of
having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
|
|
|
extern Game game;
|
2020-09-28 04:15:06 +02:00
|
|
|
#endif
|
Allow using help/graphics/music/game/key/map/obj everywhere
This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and
`obj` essentially static global objects that can be used everywhere.
This is useful in case we ever need to add a new function in the future,
so we don't have to bother with passing a new argument in which means we
have to pass a new argument in to the function that calls that function
which means having to pass a new argument into the function that calls
THAT function, etc. which is a real headache when working on fan mods of
the source code.
Note that this changes NONE of the existing function signatures, it
merely just makes those variables accessible everywhere in the same way
`script` and `ed` are.
Also note that some classes had to be initialized after the filesystem
was initialized, but C++ would keep initializing them before the
filesystem got initialized, because I *had* to put them at the top of
`main.cpp`, or else they wouldn't be global variables.
The only way to work around this was to use entityclass's initialization
style (which I'm pretty sure entityclass of all things doesn't need to
be initialized this way), where you actually initialize the class in an
`init()` function, and so then you do `graphics.init()` after the
filesystem initialization, AFTER doing `Graphics graphics` up at the
top.
I've had to do this for `graphics` (but only because its child
GraphicsResources `grphx` needs to be initialized this way), `music`,
and `game`. I don't think this will affect anything. Other than that,
`help`, `key`, and `map` are still using the C++-intended method of
having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
#endif /* GAME_H */
|
