mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-06-01 18:43:33 +02:00
Code Issues Releases Wiki Activity
96660cd235
VVVVVV/desktop_version/src/Game.cpp

6883 lines
182 KiB
C++
Raw Normal View History

Clean up and prevent unnecessary qualifiers to self By "unnecessary qualifiers to self", I mean something like using the 'game.' qualifier for a variable on the Game class when you're inside a function on the Game class itself. This patch is to enforce consistency as most of the code doesn't have these unnecessary qualifiers. To prevent further unnecessary qualifiers to self, I made it so the extern in each header file can be omitted by using a define. That way, if someone writes something referring to 'game.' on a Game function, there will be a compile error. However, if you really need to have a reference to the global name, and you're within the same .cpp file as the implementation of that object, you can just do the extern at the function-level. A good example of this is editorinput()/editorrender()/editorlogic() in editor.cpp. In my opinion, they should probably be split off into their own separate file because editor.cpp is getting way too big, but this will do for now.
2020-09-28 04:15:06 +02:00
#define GAME_DEFINITION
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "Game.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include <sstream>
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
Use angle brackets for including tinyxml2.h Since TinyXML2 is a third-party dependency, we should use angle brackets and treat it like one.
2020-07-19 21:03:16 +02:00
#include <tinyxml2.h>
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove game.shouldreturntoeditor in favor of using defer callback game.shouldreturntoeditor was added to fix a frame ordering issue that was causing a bug where if you started playtesting in a room with a horizontal/vertical warp background, and exited playtesting in a different room that also had a horizontal/vertical warp background and which was different, then the background of the room you exited in would slowly scroll offscreen, when you re-entered the editor, instead of the background consisting entirely of the actual background of the room. Namely, the issue was that the game would render one more frame of GAMEMODE after graphics.backgrounddrawn got set to false, and re-set it to true, thus negating the background redraw, so the editor background would be incorrect. With defer callbacks, we can now just use a couple lines of code, instead of having to add an extra kludge variable and putting handling for it all over the code.
2021-01-10 23:48:25 +01:00
#include "DeferCallbacks.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "editor.h"
#include "Entity.h"
#include "Enums.h"
#include "FileSystemUtils.h"
#include "Graphics.h"
Remove duplicate game.controllerSensitivity proxy It wasn't a direct duplicate of key.sensitivity, but it was still basically the same thing. Although to be fair, at least the case-switch conversion didn't get duplicated everywhere unlike game.slowdown. So now key.sensitivity functions the same as game.controllerSensitivity, and it only gets converted to its actual value whenever a joystick input happens in key.Poll(), unlike previously where it got converted every single frame on the title screen (there was even a comment that said "TODO bit wasteful doing this every poll").
2020-11-13 02:16:18 +01:00
#include "KeyPoll.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "MakeAndPlay.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "Map.h"
#include "Music.h"
#include "Network.h"
#include "Script.h"
#include "UtilityClass.h"
Add XML forwards compatibility to levelstats.vvv Not that hard to do for the smallest XML file in the game.
2020-09-25 18:09:21 +02:00
#include "XMLUtils.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Clean up unnecessary exports and add static keywords This patch cleans up unnecessary exports from header files (there were only a few), as well as adds the static keyword to all symbols that aren't exported and are specific to a file. This helps the linker out in not doing any unnecessary work, speeding it up and avoiding silent symbol conflicts (otherwise two symbols with the same name (and type/signature in C++) would quietly resolve as okay by the linker).
2021-01-10 18:14:37 +01:00
static bool GetButtonFromString(const char *pText, SDL_GameControllerButton *button)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
if (*pText == '0' ||
*pText == 'a' ||
*pText == 'A')
{
*button = SDL_CONTROLLER_BUTTON_A;
return true;
}
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
if (SDL_strcmp(pText, "1") == 0 ||
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
*pText == 'b' ||
*pText == 'B')
{
*button = SDL_CONTROLLER_BUTTON_B;
return true;
}
if (*pText == '2' ||
*pText == 'x' ||
*pText == 'X')
{
*button = SDL_CONTROLLER_BUTTON_X;
return true;
}
if (*pText == '3' ||
*pText == 'y' ||
*pText == 'Y')
{
*button = SDL_CONTROLLER_BUTTON_Y;
return true;
}
if (*pText == '4' ||
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
SDL_strcasecmp(pText, "BACK") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
*button = SDL_CONTROLLER_BUTTON_BACK;
return true;
}
if (*pText == '5' ||
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
SDL_strcasecmp(pText, "GUIDE") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
*button = SDL_CONTROLLER_BUTTON_GUIDE;
return true;
}
if (*pText == '6' ||
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
SDL_strcasecmp(pText, "START") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
*button = SDL_CONTROLLER_BUTTON_START;
return true;
}
if (*pText == '7' ||
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
SDL_strcasecmp(pText, "LS") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
*button = SDL_CONTROLLER_BUTTON_LEFTSTICK;
return true;
}
if (*pText == '8' ||
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
SDL_strcasecmp(pText, "RS") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
*button = SDL_CONTROLLER_BUTTON_RIGHTSTICK;
return true;
}
if (*pText == '9' ||
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
SDL_strcasecmp(pText, "LB") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
*button = SDL_CONTROLLER_BUTTON_LEFTSHOULDER;
return true;
}
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
if (SDL_strcmp(pText, "10") == 0 ||
SDL_strcasecmp(pText, "RB") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
*button = SDL_CONTROLLER_BUTTON_RIGHTSHOULDER;
return true;
}
return false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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 Game::init(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Un-hardreset certain variables for glitchrunner mode Ironically enough, resetting more variables in script.hardreset() makes the glitchy fadeout system even more glitchy. Resetting map.towermode, for example, makes it so that if you're in towers when you quit to the menu, script.hardreset() makes it so that the game thinks you're no longer inbounds (because it no longer thinks you're in a tower and thus considers coordinates in the space of 40x30 tiles to be inbounds instead of 40x700 or 40x100 tiles to be inbounds), calls map.gotoroom(), which resets the gamestate to 0. So if we're using the old system, it's better to reset only as much as needed. And furthermore, we shouldn't be relying on script.hardreset() to initialize variables for us. That should be done at the class constructor level. So I've gone ahead and initialized the variables in class constructors, too.
2020-06-25 23:49:54 +02:00
roomx = 0;
roomy = 0;
prevroomx = 0;
prevroomy = 0;
saverx = 0;
savery = 0;
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
mutebutton = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
muted = false;
Add being able to mute the music by pressing N This is for people who want to use their own soundtrack while playing the game, but who don't want to mute the sound effects as well. This feature was added to VCE, but it was added in the strangest way. It was made an option in "game options" instead of being a keybind, and I don't know why.
2020-04-19 21:40:59 +02:00
musicmuted = false;
musicmutebutton = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
glitchrunkludge = false;
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
gamestate = TITLEMODE;
prevgamestate = TITLEMODE;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = true;
jumpheld = false;
advancetext = false;
jumppressed = 0;
gravitycontrol = 0;
teleport = false;
edteleportent = 0; //Added in the port!
companion = 0;
roomchange = false;
quickrestartkludge = false;
tapleft = 0;
tapright = 0;
Separate pressing Enter to open map from pressing Enter to interact This is a lot of copy-pasted code, but a little bit of copy-pasting never hurt anyone... The keybind to interact with activity zones and teleporters is now separate from the keybind to open the map, or return to the editor from in-editor playtesting, or restart a time trial. The keybind is now E, and the default controller bind is X. No controller button prompts, but the game didn't have controller button prompts anyways, so whatever. Doing this now because if people's muscle memory are going to be broken by not being able to spam the map keybind anymore, at least we can help a bit by changing the keybind so they can keep spamming it - their muscle memory is going to be broken anyways. This option has to be enabled by going to the speedrunner menu options and selecting "interact button". It is disabled by default. All prompt text needs to be string-interpolated every time they are drawn, because it is possible for people to change which interact button they use in the middle of gameplay, via the in-game options. Closes #736.
2021-04-19 08:23:44 +02:00
press_right = false;
press_left = false;
press_action = false;
press_map = false;
press_interact = false;
interactheld = false;
separate_interact = false;
mapheld = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
pausescript = false;
completestop = false;
activeactivity = -1;
act_fade = 0;
Interpolate activity zone prompt fading in and out To make it real smooth, just in case it was noticeable that it only updated at 1000/34 FPS before (well, except in slowmode, it's really noticeable THERE). Also this removes the re-typing out of (game.act_fade/10.0f) for every single R, G, and B in gamerender().
2020-04-29 06:58:19 +02:00
prev_act_fade = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
backgroundtext = false;
startscript = false;
inintermission = false;
alarmon = false;
alarmdelay = 0;
blackout = false;
creditposx = 0;
creditposy = 0;
creditposdelay = 0;
Interpolate end picture reveal scroll This is so it looks smooth at framerates above 30.
2020-05-02 03:23:52 +02:00
oldcreditposx = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
useteleporter = false;
teleport_to_teleporter = 0;
activetele = false;
readytotele = 0;
Interpolate "- Press ENTER to Teleport -" prompt This is only really noticeable in slowmode, but if you're playing in slowmode it'll be pretty smooth.
2020-04-30 02:04:25 +02:00
oldreadytotele = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
activity_r = 0;
activity_g = 0;
activity_b = 0;
creditposition = 0;
Interpolate credits position So that it's as smooth as possible, especially when holding down ACTION to make it go really fast.
2020-04-30 19:56:27 +02:00
oldcreditposition = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
bestgamedeaths = -1;
//Accessibility Options
colourblindmode = false;
noflashingmode = false;
slowdown = 30;
nodeathmode = false;
nocutscenes = false;
Fix No Death Mode results being reset before being shown This does the same thing as the last commit, but for No Death Mode instead of Time Trials. Whenever you die in No Death Mode, or complete it, all the relevant variables get copied to variables prefixed with 'ndmresult' that never get reset by script.hardreset(), and these variables are what titlerender() use, instead of the "live" ones.
2021-01-08 01:18:07 +01:00
ndmresultcrewrescued = 0;
ndmresulttrinkets = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
customcol=0;
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
SDL_memset(crewstats, false, sizeof(crewstats));
Fix No Death Mode results being reset before being shown This does the same thing as the last commit, but for No Death Mode instead of Time Trials. Whenever you die in No Death Mode, or complete it, all the relevant variables get copied to variables prefixed with 'ndmresult' that never get reset by script.hardreset(), and these variables are what titlerender() use, instead of the "live" ones.
2021-01-08 01:18:07 +01:00
SDL_memset(ndmresultcrewstats, false, sizeof(ndmresultcrewstats));
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
SDL_memset(tele_crewstats, false, sizeof(tele_crewstats));
SDL_memset(quick_crewstats, false, sizeof(quick_crewstats));
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
SDL_memset(besttimes, -1, sizeof(besttimes));
Fix memset writing past bestframes
2020-07-01 05:02:18 +02:00
SDL_memset(bestframes, -1, sizeof(bestframes));
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
SDL_memset(besttrinkets, -1, sizeof(besttrinkets));
SDL_memset(bestlives, -1, sizeof(bestlives));
SDL_memset(bestrank, -1, sizeof(bestrank));
Simplify std::vector initializations Resizing the vector does the same thing that the loops did, it changes the size for the vector and initializes it with default-constructed elements (or 0 or its equivalent for POD types). Where a specific value is needed, it is set with the second parameter of resize().
2020-01-12 12:28:34 +01:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
crewstats[0] = true;
lastsaved = 0;
tele_gametime = "00:00";
tele_trinkets = 0;
tele_currentarea = "Error! Error!";
quick_gametime = "00:00";
quick_trinkets = 0;
quick_currentarea = "Error! Error!";
//Menu stuff initiliased here:
Turn unlock/unlocknotify into plain arrays They're always fixed-size, so there's no need to them to be a dynamic vector. I changed their type to `bool` too because they don't need to be `int`s. Also, I replaced the hardcoded 25 constant with at least a name, in case people want to change it in the future.
2020-07-03 01:45:22 +02:00
SDL_memset(unlock, false, sizeof(unlock));
SDL_memset(unlocknotify, false, sizeof(unlock));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
currentmenuoption = 0;
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
current_credits_list_index = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuxoff = 0;
menuyoff = 0;
menucountdown = 0;
levelpage=0;
playcustomlevel=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
createmenu(Menu::mainmenu);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add error messages for failed writes to disk of settings Changing settings would most of the time attempt to save unlock.vvv and now also settings.vvv, but there would be no feedback whether the files have been saved successfully or not. Now, if saving fails when changing settings in the menu, a warning message will be shown. The setting will still be applied of course, but the user will be informed it couldn't be saved. This message can be silenced until the game is restarted, because I can imagine this could get very annoying when someone already knows their settings aren't writeable. Also, some options didn't even save settings in the first place. These are turning off invincibility, and by coincidence precisely all the options in the advanced options menu. I made sure these options now do so.
2020-11-22 03:10:26 +01:00
silence_settings_error = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
deathcounts = 0;
gameoverdelay = 0;
De-duplicate zeroing the game clock For some reason, resetgameclock() is only ever used in gamerender(), and everywhere else just zeroes the clock manually. This is weird to me, so I've made it so everywhere that zeroes the clock uses the resetgameclock() function to do so.
2021-04-13 23:36:21 +02:00
resetgameclock();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
gamesaved = false;
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
gamesavefailed = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
savetime = "00:00";
savearea = "nowhere";
savetrinkets = 0;
intimetrial = false;
timetrialcountdown = 0;
timetrialshinytarget = 0;
timetrialparlost = false;
timetrialpar = 0;
timetrialresulttime = 0;
Display centiseconds on time trial result and Game Complete Centiseconds won't be saved to any save file or anything. This is just to make speedrunning a bit more competitive, being able to know the precise time of a time trial or full game run. The time trial par time on the result screen always has ".99" after it. This is basically due to the game comparing the number of seconds to the par number of seconds using less-than-or-equal-to instead of simply less-than.
2020-06-30 00:53:19 +02:00
timetrialresultframes = 0;
Fix Time Trial results being reset before being shown This makes it so when a Time Trial gets completed, all the relevant variables get copied onto variables prefixed with 'timetrialresult', which never get reset by script.hardreset(). Then titlerender() will use those variables accordingly.
2021-01-08 01:02:45 +01:00
timetrialresultshinytarget = 0;
timetrialresulttrinkets = 0;
timetrialresultpar = 0;
timetrialresultdeaths = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
totalflips = 0;
hardestroom = "Welcome Aboard";
hardestroomdeaths = 0;
currentroomdeaths=0;
inertia = 1.1f;
swnmode = false;
swntimer = 0;
swngame = 0;//Not playing sine wave ninja!
swnstate = 0;
swnstate2 = 0;
swnstate3 = 0;
swnstate4 = 0;
swndelay = 0;
swndeaths = 0;
supercrewmate = false;
scmhurt = false;
scmprogress = 0;
scmmoveme = false;
swncolstate = 0;
swncoldelay = 0;
swnrecord = 0;
swnbestrank = 0;
swnrank = 0;
swnmessage = 0;
clearcustomlevelstats();
saveFilePath = FILESYSTEM_getUserSaveDirectory();
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
tinyxml2::XMLDocument doc;
if (!FILESYSTEM_loadTiXml2Document("saves/qsave.vvv", doc))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
quicksummary = "";
printf("Quick Save Not Found\n");
}
else
{
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
tinyxml2::XMLHandle hRoot(NULL);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
pElem=hDoc.FirstChildElement().ToElement();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (!pElem)
{
printf("Quick Save Appears Corrupted: No XML Root\n");
}
// save this for later
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
hRoot=tinyxml2::XMLHandle(pElem);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
for( pElem = hRoot.FirstChildElement( "Data" ).FirstChild().ToElement(); pElem; pElem=pElem->NextSiblingElement())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
const char* pKey = pElem->Value();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
const char* pText = pElem->GetText() ;
Add missing pText NULL checks If an XML tag doesn't contain anything inside, pText will be NULL. If that happens without being checked, then NULL will be passed to SDL_strcmp(). SDL_strcmp() will either call libc strcmp() or use its own implementation; both implementations will still dereference the NULL without checking it. This is undefined behavior, so I'm fixing it. The solution is to do what is done with all other XML parsing functions, and to make sure pText gets set to a safe empty string (which is just a pointer to a null terminator) if it happens to be NULL.
2021-03-24 20:19:44 +01:00
if (pText == NULL)
{
pText = "";
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "summary") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
quicksummary = pText;
}
}
}
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
tinyxml2::XMLDocument docTele;
if (!FILESYSTEM_loadTiXml2Document("saves/tsave.vvv", docTele))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
telesummary = "";
printf("Teleporter Save Not Found\n");
}
else
{
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
tinyxml2::XMLHandle hDoc(&docTele);
tinyxml2::XMLElement* pElem;
tinyxml2::XMLHandle hRoot(NULL);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
pElem=hDoc.FirstChildElement().ToElement();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
// should always have a valid root but handle gracefully if it does
if (!pElem)
{
printf("Teleporter Save Appears Corrupted: No XML Root\n");
}
// save this for later
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
hRoot=tinyxml2::XMLHandle(pElem);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
for( pElem = hRoot.FirstChildElement( "Data" ).FirstChild().ToElement(); pElem; pElem=pElem->NextSiblingElement())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
const char* pKey = pElem->Value();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
const char* pText = pElem->GetText() ;
Add missing pText NULL checks If an XML tag doesn't contain anything inside, pText will be NULL. If that happens without being checked, then NULL will be passed to SDL_strcmp(). SDL_strcmp() will either call libc strcmp() or use its own implementation; both implementations will still dereference the NULL without checking it. This is undefined behavior, so I'm fixing it. The solution is to do what is done with all other XML parsing functions, and to make sure pText gets set to a safe empty string (which is just a pointer to a null terminator) if it happens to be NULL.
2021-03-24 20:19:44 +01:00
if (pText == NULL)
{
pText = "";
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "summary") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
telesummary = pText;
}
}
}
screenshake = flashlight = 0 ;
stat_trinkets = 0;
state = 1;
statedelay = 0;
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
//updatestate();
Add an accessibility option to toggle the fake loading screen (#63)
2020-01-13 02:45:44 +01:00
skipfakeload = false;
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
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
ghostsenabled = false;
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
cliplaytest = false;
playx = 0;
playy = 0;
playrx = 0;
playry = 0;
playgc = 0;
Move fading to menu to separate variables Alright, so what I've done here is made exiting to the menu entirely separate from Terry's State Machine, and thus it can now take place entirely within MAPMODE instead of having to go back to GAMEMODE. Also, it's faster by 15 frames since we don't need to wait for the map screen to go back down.
2020-05-08 00:23:55 +02:00
fadetomenu = false;
fadetomenudelay = 0;
Move returning to lab to separate variables Again, what I've done here is removed the over-reliance on Terry's State Machine to return to the lab, and just moved it into separate variables instead. This means that returning to the lab is ALMOST entirely self-contained in MAPMODE, except there's a quick jaunt over to GAMEMODE to run a script because you can only run scripts in GAMEMODE.
2020-05-08 00:30:26 +02:00
fadetolab = false;
fadetolabdelay = 0;
Move fading to menu to separate variables Alright, so what I've done here is made exiting to the menu entirely separate from Terry's State Machine, and thus it can now take place entirely within MAPMODE instead of having to go back to GAMEMODE. Also, it's faster by 15 frames since we don't need to wait for the map screen to go back down.
2020-05-08 00:23:55 +02:00
Default to 60 FPS mode (fixes #702)
2021-04-09 12:10:22 +02:00
over30mode = true;
Add glitchrunner mode, in game options Glitchrunner mode is intended to re-enable glitches that existed in older versions of VVVVVV. These glitches were removed because they could legitimately affect a casual player's experience. Glitches like various R-pressing screwery, Space Station 1 skip, telejumping, Gravitron out-of-bounds, etc. will not be patched.
2020-06-25 23:31:37 +02:00
glitchrunnermode = false;
Make returning from game/graphic options return to MAPMODE This is so return doesn't just lead back to more TITLEMODE.
2020-06-23 01:51:16 +02:00
ingame_titlemode = false;
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)
ingame_editormode = false;
#endif
Save current menu to temp variable when entering options from in-game This is to pre-emptively prevent piling up stack frames for what I'll be adding next, which is pressing Esc in the options menu in-game automatically moving you back to MAPMODE.
2020-06-23 02:23:56 +02:00
kludge_ingametemp = Menu::mainmenu;
Implement music and sound volume sliders This adds music and volume sliders to the audio options. To use the sliders, you navigate to the given option, then press ACTION, and your selection will be transferred to the slider. Pressing left or right will move the slider accordingly. Then you can press ACTION to confirm the volume is what you want and deselect it, or you can press Esc to cancel the volume change, and it will revert to the previous volume; both actions will write your settings to disk. Most of this commit is just adding infrastructure to support having sliders in menus (without copy-pasting code), which is a totally completely new user interface that has never been used before in this game. If we're going to be adding something new, I want to make sure that it at least is done the RIGHT way. Closes #706.
2021-04-12 02:43:17 +02:00
slidermode = SLIDER_NONE;
Add being able to toggle over/fixed-30-FPS, off by default There is now an option in "graphic options" named "toggle fps", which toggles whether the game visually runs at 1000/34 FPS or over 1000/34 FPS. It is off by default. I've had to put the entire game loop in yet another set of braces, I'll indent it next commit.
2020-05-04 21:52:57 +02:00
Add being able to disable unfocus pause It's sometimes unwanted by people, and it's unwanted enough that there exist instructions to hexedit the binary to remove it ( https://distractionware.com/forum/index.php?topic=3247.0 ). Fun fact, the unfocus pause didn't exist in 2.0.
2020-06-30 04:49:14 +02:00
disablepause = false;
Add option to re-enable 1-frame input delay This is an option for speedrunners whose muscle memory is precisely trained and used to the 1-frame input delay that existed in 2.2 and below. It is located in Game Options -> Advanced Options, and is off by default. To re-add the 1-frame input delay, we simply move the key.Poll() to the start of the frame, instead of before an input function gets ran - undoing what #535 did. There is a frame ordering-sensitive issue here, where toggling game.inputdelay at the wrong time could cause double-polling. However, we only toggle it in an input function, which regardless is always guaranteed to be ran after key.Poll() (it either happened at the start of the frame or just before the input function got ran), so this is not an issue. But, in case we ever need to toggle this variable in the future, we can just use the defer callbacks system to defer the toggle to the end of the frame - also added by #535. Added at the request of Habeechee on the VVVVVV speedrunning Discord server.
2021-04-02 00:39:56 +02:00
inputdelay = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::lifesequence(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (lifeseq > 0)
{
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].invis = false;
if (lifeseq == 2) obj.entities[i].invis = true;
if (lifeseq == 6) obj.entities[i].invis = true;
if (lifeseq >= 8) obj.entities[i].invis = true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (lifeseq > 5) gravitycontrol = savegc;
lifeseq--;
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities) && lifeseq <= 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[i].invis = false;
}
}
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::clearcustomlevelstats(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
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
//just clearing the array
customlevelstats.clear();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
void Game::updatecustomlevelstats(std::string clevel, int cscore)
{
if (clevel.find("levels/") != std::string::npos)
{
clevel = clevel.substr(7);
}
int tvar=-1;
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
for(size_t j=0; j<customlevelstats.size(); j++)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
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
if(clevel==customlevelstats[j].name)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
tvar=j;
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
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Fix duplicate levels in levelstats if you don't have a higher score This is a regression from 25779606b499819de50151cd20aab406256315f5 (PR #74). On the one hand, I should've thought this through carefully when implementing the fix for the lower-score overwrite bug. On the other hand, flibit didn't seem to notice either. And on the third hand, no one else seems to have noticed, when they have had over 8 months to do so. Not even the person who originally reported the lower-score overwrite bug and also reported other bugs I hadn't noticed (e.g. the "You have rescued a crewmate!" in Flip Mode) noticed this bug, which I believe was weee50. But to be fair, he does seem to be less active nowadays. On the fourth hand, I only realized the cause of the duplicate bug after stepping through it in GDB, instead of just looking at it and going "hey wait a minute" earlier. I'm surprised it didn't take me longer to realize the problem. I'm not sure what all these hands mean anymore, or where I'm getting extra hands from. Whatever. This regression is fixed now.
2020-09-13 06:55:26 +02:00
if(tvar>=0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix duplicate levels in levelstats if you don't have a higher score This is a regression from 25779606b499819de50151cd20aab406256315f5 (PR #74). On the one hand, I should've thought this through carefully when implementing the fix for the lower-score overwrite bug. On the other hand, flibit didn't seem to notice either. And on the third hand, no one else seems to have noticed, when they have had over 8 months to do so. Not even the person who originally reported the lower-score overwrite bug and also reported other bugs I hadn't noticed (e.g. the "You have rescued a crewmate!" in Flip Mode) noticed this bug, which I believe was weee50. But to be fair, he does seem to be less active nowadays. On the fourth hand, I only realized the cause of the duplicate bug after stepping through it in GDB, instead of just looking at it and going "hey wait a minute" earlier. I'm surprised it didn't take me longer to realize the problem. I'm not sure what all these hands mean anymore, or where I'm getting extra hands from. Whatever. This regression is fixed now.
2020-09-13 06:55:26 +02:00
// We have an existing entry
// Don't update it unless it's a higher score
if (cscore > customlevelstats[tvar].score)
{
customlevelstats[tvar].score=cscore;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
//add a new entry
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
CustomLevelStat levelstat = {clevel, cscore};
customlevelstats.push_back(levelstat);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
savecustomlevelstats();
}
Move LOAD_ARRAY[_RENAME] macros to before loadcustomlevelstats() In order to be able to use the LOAD_ARRAY() and LOAD_ARRAY_RENAME() macros in Game::loadcustomlevelstats(), they have to be moved to earlier in the file.
2021-02-12 21:13:54 +01:00
#define LOAD_ARRAY_RENAME(ARRAY_NAME, DEST) \
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, #ARRAY_NAME) == 0 && pText[0] != '\0') \
Move LOAD_ARRAY[_RENAME] macros to before loadcustomlevelstats() In order to be able to use the LOAD_ARRAY() and LOAD_ARRAY_RENAME() macros in Game::loadcustomlevelstats(), they have to be moved to earlier in the file.
2021-02-12 21:13:54 +01:00
{ \
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
/* We're loading in 32-bit integers. If we need more than 16 chars,
* something is seriously wrong */ \
char buffer[16]; \
size_t start = 0; \
size_t i = 0; \
\
while (next_split_s(buffer, sizeof(buffer), &start, pText, ',')) \
Unindent from collapsing empty pText check As always, the diff algorithms do terribly with unindentation, so I'm doing the actual unindenting in this commit.
2021-02-12 22:53:01 +01:00
{ \
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
if (i >= SDL_arraysize(DEST)) \
{ \
break; \
} \
\
DEST[i] = help.Int(buffer); \
++i; \
Unindent from collapsing empty pText check As always, the diff algorithms do terribly with unindentation, so I'm doing the actual unindenting in this commit.
2021-02-12 22:53:01 +01:00
} \
Move LOAD_ARRAY[_RENAME] macros to before loadcustomlevelstats() In order to be able to use the LOAD_ARRAY() and LOAD_ARRAY_RENAME() macros in Game::loadcustomlevelstats(), they have to be moved to earlier in the file.
2021-02-12 21:13:54 +01:00
}
#define LOAD_ARRAY(ARRAY_NAME) LOAD_ARRAY_RENAME(ARRAY_NAME, ARRAY_NAME)
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 Game::loadcustomlevelstats(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
tinyxml2::XMLDocument doc;
if (!FILESYSTEM_loadTiXml2Document("saves/levelstats.vvv", doc))
{
//No levelstats file exists; start new
customlevelstats.clear();
savecustomlevelstats();
return;
}
// Old system
std::vector<std::string> customlevelnames;
std::vector<int> customlevelscores;
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
tinyxml2::XMLHandle hRoot(NULL);
{
pElem=hDoc.FirstChildElement().ToElement();
// should always have a valid root but handle gracefully if it does
if (!pElem)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
printf("Error: Levelstats file corrupted\n");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Use returns and don't have rest of loadcustomlevelstats in an 'else' This will cut down on unnecessary indentation levels.
2020-06-30 03:44:54 +02:00
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
// save this for later
hRoot=tinyxml2::XMLHandle(pElem);
}
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
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
// First pass, look for the new system of storing stats
// If they don't exist, then fall back to the old system
for (pElem = hRoot.FirstChildElement("Data").FirstChild().ToElement(); pElem; pElem = pElem->NextSiblingElement())
{
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
const char* pKey = pElem->Value();
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
const char* pText = pElem->GetText();
if (pText == NULL)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
pText = "";
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "stats") == 0)
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
{
for (tinyxml2::XMLElement* stat_el = pElem->FirstChildElement(); stat_el; stat_el = stat_el->NextSiblingElement())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
CustomLevelStat stat = {};
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
if (stat_el->GetText() != NULL)
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
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
stat.score = help.Int(stat_el->GetText());
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
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
if (stat_el->Attribute("name"))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
stat.name = stat_el->Attribute("name");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
customlevelstats.push_back(stat);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
return;
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
// Since we're still here, we must be on the old system
for( pElem = hRoot.FirstChildElement( "Data" ).FirstChild().ToElement(); pElem; pElem=pElem->NextSiblingElement())
{
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
const char* pKey = pElem->Value();
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
const char* pText = pElem->GetText() ;
if(pText == NULL)
{
pText = "";
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Fix level list segfault when upgrading old levelstats.vvv So some people reported the levels list crashing when they loaded it. But this wasn't reproducible every time. They didn't provide any debugging information, so I had to use my backup plan: doing a full audit of the code path taken for loading the levels list. And then I found this. It turns out this was because I used a LOAD_ARRAY_RENAME() macro on an std::vector. You can't do that because you need to use push_back() to resize a vector, so the macro will end up indexing into nothing, causing a segfault. However, this code path would only be taken if you have an old levelstats.vvv, from 2.2 and previous - which explains why it wasn't 100% reproducible. But now that I know you need an old levelstats.vvv, this bug happens 100% of the time. Anyways, to fix this, just ditch the macro and expand it manually, while replacing the indexing with a proper usage of push_back().
2021-04-09 17:45:24 +02:00
if (SDL_strcmp(pKey, "customlevelscore") == 0 && pText[0] != '\0')
{
char buffer[16];
size_t start = 0;
while (next_split_s(buffer, sizeof(buffer), &start, pText, ','))
{
customlevelscores.push_back(help.Int(buffer));
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "customlevelstats") == 0 && pText[0] != '\0')
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
{
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
size_t start = 0;
size_t len = 0;
size_t prev_start = 0;
while (next_split(&start, &len, &pText[start], '|'))
Unindent from collapsing empty pText check As always, the diff algorithms do terribly with unindentation, so I'm doing the actual unindenting in this commit.
2021-02-12 22:53:01 +01:00
{
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
customlevelnames.push_back(std::string(&pText[prev_start], len));
prev_start = start;
Unindent from collapsing empty pText check As always, the diff algorithms do terribly with unindentation, so I'm doing the actual unindenting in this commit.
2021-02-12 22:53:01 +01:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
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
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
// If the two arrays happen to differ in length, just go with the smallest one
Reduce dependency on libc functions During 2.3 development, there's been a gradual shift to using SDL stdlib functions instead of libc functions, but there are still some libc functions (or the same libc function but from the STL) in the code. Well, this patch replaces all the rest of them in one fell swoop. SDL's stdlib can replace most of these, but its SDL_min() and SDL_max() are inadequate - they aren't really functions, they're more like macros with a nasty penchant for double-evaluation. So I just made my own VVV_min() and VVV_max() functions and placed them in Maths.h instead, then replaced all the previous usages of min(), max(), std::min(), std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max(). Additionally, there's no SDL_isxdigit(), so I just implemented my own VVV_isxdigit(). SDL has SDL_malloc() and SDL_free(), but they have some refcounting built in to them, so in order to use them with LodePNG, I have to replace the malloc() and free() that LodePNG uses. Which isn't too hard, I did it in a new file called ThirdPartyDeps.c, and LodePNG is now compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition. Lastly, I also refactored the awful strcpy() and strcat() usages in PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save migration is getting axed in 2.4, but it still bothers me to have something like that in the codebase otherwise. Without further ado, here is the full list of functions that the codebase now uses: - SDL_strlcpy() instead of strcpy() - SDL_strlcat() instead of strcat() - SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above) - VVV_min() instead of min(), std::min(), or SDL_min() - VVV_max() instead of max(), std::max(), or SDL_max() - VVV_isxdigit() instead of isxdigit() - SDL_strcmp() instead of strcmp() - SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi() - SDL_strstr() instead of strstr() - SDL_strlen() instead of strlen() - SDL_sscanf() instead of sscanf() - SDL_getenv() instead of getenv() - SDL_malloc() instead of malloc() (replacing in LodePNG as well) - SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
for (int i = 0; i < VVV_min(customlevelnames.size(), customlevelscores.size()); i++)
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
{
CustomLevelStat stat = {customlevelnames[i], customlevelscores[i]};
customlevelstats.push_back(stat);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::savecustomlevelstats(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::savecustomlevelstats() to TinyXML2
2020-06-04 04:32:18 +02:00
tinyxml2::XMLDocument doc;
Add XML forwards compatibility to levelstats.vvv Not that hard to do for the smallest XML file in the game.
2020-09-25 18:09:21 +02:00
bool already_exists = FILESYSTEM_loadTiXml2Document("saves/levelstats.vvv", doc);
if (!already_exists)
{
puts("No levelstats.vvv found. Creating new file");
}
xml::update_declaration(doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to levelstats.vvv Not that hard to do for the smallest XML file in the game.
2020-09-25 18:09:21 +02:00
tinyxml2::XMLElement * root = xml::update_element(doc, "Levelstats");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to levelstats.vvv Not that hard to do for the smallest XML file in the game.
2020-09-25 18:09:21 +02:00
xml::update_comment(root, " Levelstats Save file ");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to levelstats.vvv Not that hard to do for the smallest XML file in the game.
2020-09-25 18:09:21 +02:00
tinyxml2::XMLElement * msgs = xml::update_element(root, "Data");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
int numcustomlevelstats = customlevelstats.size();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if(numcustomlevelstats>=200)numcustomlevelstats=199;
Add XML forwards compatibility to levelstats.vvv Not that hard to do for the smallest XML file in the game.
2020-09-25 18:09:21 +02:00
xml::update_tag(msgs, "numcustomlevelstats", numcustomlevelstats);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string customlevelscorestr;
for(int i = 0; i < numcustomlevelstats; i++ )
{
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
customlevelscorestr += help.String(customlevelstats[i].score) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to levelstats.vvv Not that hard to do for the smallest XML file in the game.
2020-09-25 18:09:21 +02:00
xml::update_tag(msgs, "customlevelscore", customlevelscorestr.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string customlevelstatsstr;
for(int i = 0; i < numcustomlevelstats; i++ )
{
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
customlevelstatsstr += customlevelstats[i].name + "|";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to levelstats.vvv Not that hard to do for the smallest XML file in the game.
2020-09-25 18:09:21 +02:00
xml::update_tag(msgs, "customlevelstats", customlevelstatsstr.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
// New system
Add XML forwards compatibility to levelstats.vvv Not that hard to do for the smallest XML file in the game.
2020-09-25 18:09:21 +02:00
tinyxml2::XMLElement* msg = xml::update_element_delete_contents(msgs, "stats");
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
tinyxml2::XMLElement* stat_el;
for (size_t i = 0; i < customlevelstats.size(); i++)
{
stat_el = doc.NewElement("stat");
CustomLevelStat& stat = customlevelstats[i];
stat_el->SetAttribute("name", stat.name.c_str());
stat_el->LinkEndChild(doc.NewText(help.String(stat.score).c_str()));
msg->LinkEndChild(stat_el);
}
Convert Game::savecustomlevelstats() to TinyXML2
2020-06-04 04:32:18 +02:00
if(FILESYSTEM_saveTiXml2Document("saves/levelstats.vvv", doc))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
printf("Level stats saved\n");
}
else
{
printf("Could Not Save level stats!\n");
Make saveFilePath not an std::string Since it only ever gets assigned from FILESYSTEM_getUserSaveDirectory(), and that function returns a C string, and the variable is only ever read from again, this doesn't need to be an std::string.
2021-03-07 00:30:22 +01:00
printf("Failed: %s%s\n", saveFilePath, "levelstats.vvv");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
void Game::levelcomplete_textbox(void)
{
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme("", -1, 12, 165, 165, 255);
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
graphics.addline(" ");
graphics.addline("");
graphics.addline("");
graphics.textboxcenterx();
}
void Game::crewmate_textbox(const int r, const int g, const int b)
{
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme("", -1, 64 + 8 + 16, r, g, b);
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
graphics.addline(" You have rescued ");
graphics.addline(" a crew member! ");
graphics.addline("");
graphics.textboxcenterx();
}
void Game::remaining_textbox(void)
{
const int remaining = 6 - crewrescued();
const char* string;
char buffer[161]; /* 4 bytes per 40 chars (whole screen) plus 1 for null terminator */
if (remaining == 1)
{
string = " One remains ";
}
else if (remaining > 0)
{
SDL_snprintf(
buffer,
sizeof(buffer),
" %s remain ",
help.number(remaining).c_str()
);
string = buffer;
}
else
{
string = " All Crew Members Rescued! ";
}
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme(string, -1, 128 + 16, 174, 174, 174);
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
graphics.textboxcenterx();
}
void Game::actionprompt_textbox(void)
{
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme(" Press ACTION to continue ", -1, 196, 164, 164, 255);
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
graphics.textboxcenterx();
}
De-duplicate "Game Saved" telesave textbox The "Game Saved" text box, along with its associated telesave() call, exists in both Game.cpp and Script.cpp, so one of them is the copy-paste of the other. Unfortunately this copy-paste resulted in an inconsistency where both of them don't check for the same things when deciding whether or not the telesave should actually happen (this is why you don't copy-paste, kids... it's scary!). Either way, de-duplicating this now is less work for me later.
2021-03-20 03:40:16 +01:00
void Game::savetele_textbox(void)
{
if (inspecial() || map.custommode)
{
return;
}
if (savetele())
{
graphics.createtextboxflipme(" Game Saved ", -1, 12, 174, 174, 174);
graphics.textboxtimer(25);
}
else
{
graphics.createtextboxflipme(" ERROR: Could not save game! ", -1, 12, 255, 60, 60);
graphics.textboxtimer(50);
}
}
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 Game::updatestate(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
statedelay--;
if(statedelay<=0){
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
statedelay=0;
glitchrunkludge=false;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (statedelay <= 0)
{
switch(state)
{
case 0:
//Do nothing here! Standard game state
Add catch-all softlock protection What this simply does is make it so that in the event that game.hascontrol is somehow set to false when there isn't a cutscene running (i.e. when game.state is 0 and script.running is false), it gets set back to true again. There's many ways to interrupt a gamestate and/or a running script, most notably telejumping and doing a screen transition in the middle of the animation, interrupting it. This implements the first part of my idea in this comment: https://github.com/TerryCavanagh/VVVVVV/issues/391#issuecomment-659757071
2020-08-03 00:39:21 +02:00
Fix softlocks from turning off advancetext at wrong time When a text box in the script system (not the gamestate system) is displayed onscreen and "- Press ACTION to advance text -" is up, the game sets pausescript to true, so the script system won't blare past the text box and keep executing. Then it also sets advancetext to true. Crucially, these two variables are different, so if you have pausescript true but advancetext false, then what happens? Well, you get softlocked. There's no way to continue the script. How is this possible? Well, you can teleport to the (0,0) teleporter (the teleporter in the very top-left of the map) and regain control during the teleporter animation. To do that, in 2.2 and below, you have to press R at the same time you press Enter on the teleporter, or in 2.3 you can simply press R during the cutscene. Then once you teleport to the room, it's really precise and a bit difficult (especially if Viridian is invisible), but you can quickly walk over to the terminal in that room and press Enter on it. Then what will happen is the terminal script will run, but the teleporter gamestate sequence will finish and turn advancetext off in the middle of it. And then you're softlocked. To fix this, just add a check so if we're in gamestate 0 and there's a script running, but we have pausescript on and advancetext off, just turn pausescript off so the game automatically advances the script. This softlock was reported by Tzann on the VVVVVV speedrunning Discord.
2021-04-11 03:15:43 +02:00
if (script.running)
Add catch-all softlock protection What this simply does is make it so that in the event that game.hascontrol is somehow set to false when there isn't a cutscene running (i.e. when game.state is 0 and script.running is false), it gets set back to true again. There's many ways to interrupt a gamestate and/or a running script, most notably telejumping and doing a screen transition in the middle of the animation, interrupting it. This implements the first part of my idea in this comment: https://github.com/TerryCavanagh/VVVVVV/issues/391#issuecomment-659757071
2020-08-03 00:39:21 +02:00
{
Fix softlocks from turning off advancetext at wrong time When a text box in the script system (not the gamestate system) is displayed onscreen and "- Press ACTION to advance text -" is up, the game sets pausescript to true, so the script system won't blare past the text box and keep executing. Then it also sets advancetext to true. Crucially, these two variables are different, so if you have pausescript true but advancetext false, then what happens? Well, you get softlocked. There's no way to continue the script. How is this possible? Well, you can teleport to the (0,0) teleporter (the teleporter in the very top-left of the map) and regain control during the teleporter animation. To do that, in 2.2 and below, you have to press R at the same time you press Enter on the teleporter, or in 2.3 you can simply press R during the cutscene. Then once you teleport to the room, it's really precise and a bit difficult (especially if Viridian is invisible), but you can quickly walk over to the terminal in that room and press Enter on it. Then what will happen is the terminal script will run, but the teleporter gamestate sequence will finish and turn advancetext off in the middle of it. And then you're softlocked. To fix this, just add a check so if we're in gamestate 0 and there's a script running, but we have pausescript on and advancetext off, just turn pausescript off so the game automatically advances the script. This softlock was reported by Tzann on the VVVVVV speedrunning Discord.
2021-04-11 03:15:43 +02:00
if (pausescript && !advancetext)
{
/* Prevent softlocks if we somehow don't have advancetext */
pausescript = false;
}
}
else
{
/* Prevent softlocks if there's no cutscene running right now */
Add catch-all softlock protection What this simply does is make it so that in the event that game.hascontrol is somehow set to false when there isn't a cutscene running (i.e. when game.state is 0 and script.running is false), it gets set back to true again. There's many ways to interrupt a gamestate and/or a running script, most notably telejumping and doing a screen transition in the middle of the animation, interrupting it. This implements the first part of my idea in this comment: https://github.com/TerryCavanagh/VVVVVV/issues/391#issuecomment-659757071
2020-08-03 00:39:21 +02:00
hascontrol = true;
Fix softlocks from mistimed trinket text skip You can skip the "You have found a shiny trinket!" cutscene. The conditions are that this can only be done in the main game, in the main dimension (no Polar Dimension), the checkpoint that you last touched must not be in the same room as the trinket, and you have to have skipped the Comms Relay cutscene. To do the skip, you press R on the exact frame (or previous frame, if input delay is enabled) that Viridian touches the trinket. Then, the gamestate will be immediately set to 0 (because of the gotoroom) and the cutscene will be skipped. Speedrunners of the main game, well, run the main game already, the only trinket in the Polar Dimension is not one you want to do a death warp at, and they have a habit of automatically skipping over the Comms Relay cutscene because they press R at the beginning of the run when Viridian teleports to Welcome Aboard, to warp back to the Ship and so they can leave rescuing Violet for later. So someone reported softlocking themselves by doing the trinket text skip in 2.3. The softlock is because they're stuck in a state where completestop is true but can't advance to a state that turns it off. How does this happen? It's because they pressed R too late and interrupted the gamestate sequence. In 2.2 and previous, if you're in the gamestate sequence then you can't press R at all, but 2.3 removes this restriction (on account of aiming to prevent softlocks). So only on the very first frame can you death warp and interrupt the gamestate sequence before it happens at all. Anyways to fix this, just turn completestop off automatically if we're in gamestate 0 and there's no script running. This softlock was reported by Euni on the VVVVVV speedrunning Discord.
2021-04-11 00:38:46 +02:00
completestop = false;
Add catch-all softlock protection What this simply does is make it so that in the event that game.hascontrol is somehow set to false when there isn't a cutscene running (i.e. when game.state is 0 and script.running is false), it gets set back to true again. There's many ways to interrupt a gamestate and/or a running script, most notably telejumping and doing a screen transition in the middle of the animation, interrupting it. This implements the first part of my idea in this comment: https://github.com/TerryCavanagh/VVVVVV/issues/391#issuecomment-659757071
2020-08-03 00:39:21 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 1:
//Game initilisation
state = 0;
break;
case 2:
//Opening cutscene
advancetext = true;
hascontrol = false;
state = 3;
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
graphics.createtextbox("To do: write quick", 50, 80, 164, 164, 255);
graphics.addline("intro to story!");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Oh no! what happen to rest of crew etc crash into dimension
break;
case 4:
//End of opening cutscene for now
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
graphics.createtextbox(" Press arrow keys or WASD to move ", -1, 195, 174, 174, 174);
graphics.textboxtimer(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 5:
//Demo over
advancetext = true;
hascontrol = false;
startscript = true;
newscript="returntohub";
obj.removetrigger(5);
state = 6;
break;
case 7:
//End of opening cutscene for now
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = true;
advancetext = false;
state = 0;
break;
case 8:
//Enter dialogue
obj.removetrigger(8);
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 (!obj.flags[13])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[13] = 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
graphics.createtextbox(" Press ENTER to view map ", -1, 155, 174, 174, 174);
graphics.addline(" and quicksave");
graphics.textboxtimer(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
state = 0;
break;
case 9:
Move Secret Lab nocompetitive check to Super Gravitron It turns out, despite the game attempting to prevent you from using invincibility or slowdown in the Super Gravitron by simply preventing you from entering the Secret Lab from the menu, it's still possible to enter the Super Gravitron with it anyways. Just have invincibility or slowdown (or both!) enabled, enter the game normally, and talk to Victoria when you have 20 trinkets, to start the epilogue cutscene. Yeah, that's a pretty big gaping hole right there... It's also possible to do a trick that speedrunners use called telejumping to the Secret Lab to bypass the invincibility/slowdown check, too. So rather than single-case patch both of these, I'm going to fix it as generally as possible, by moving the invincibility/slowdown check to the gamestate that starts the Super Gravitron, gamestate 9. If you have invincibility/slowdown enabled, you immediately get sent back to the Secret Lab. However, this check is ignored in custom levels, because custom levels may want to use the Super Gravitron and let players have invincibility/slowdown while doing so (and there are in fact custom levels out in the wild that use the Super Gravitron; it was like one of the first things done when people discovered internal scripting). No message pops up when the game sends you back to the Secret Lab, but no message popped up when the Secret Lab menu option was disabled previously in the first place, so I haven't made anything WORSE, per se. A nice effect of this is that you can have invincibility/slowdown enabled and still be able to go to the Secret Lab from the menu. This is useful if you just want to check your trophies and leave, without having to go out of your way to disable invincibility/slowdown just to go inside.
2021-05-04 03:57:13 +02:00
if (!map.custommode && nocompetitive())
{
returntolab();
state = 0;
break;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Start SWN Minigame Mode B
obj.removetrigger(9);
swnmode = true;
swngame = 6;
swndelay = 150;
swntimer = 60 * 30;
//set the checkpoint in the middle of the screen
savepoint = 0;
savex = 148;
savey = 100;
savegc = 0;
saverx = roomx;
savery = roomy;
savedir = 0;
state = 0;
break;
case 10:
//Start SWN Minigame Mode A
obj.removetrigger(10);
swnmode = true;
swngame = 4;
swndelay = 150;
swntimer = 60 * 30;
//set the checkpoint in the middle of the screen
savepoint = 0;
savex = 148;
savey = 100;
savegc = 0;
saverx = roomx;
savery = roomy;
savedir = 0;
state = 0;
break;
case 11:
//Intermission 1 instructional textbox, depends on last saved
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
graphics.textboxremovefast();
graphics.createtextbox(" When you're NOT standing on ", -1, 3, 174, 174, 174);
if (graphics.flipmode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (lastsaved == 2)
{
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
graphics.addline(" the ceiling, Vitellary will");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 3)
{
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
graphics.addline(" the ceiling, Vermilion will");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 4)
{
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
graphics.addline(" the ceiling, Verdigris will");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 5)
{
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
graphics.addline(" the ceiling, Victoria will");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else
{
if (lastsaved == 2)
{
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
graphics.addline(" the floor, Vitellary will");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 3)
{
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
graphics.addline(" the floor, Vermilion will");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 4)
{
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
graphics.addline(" the floor, Verdigris will");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 5)
{
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
graphics.addline(" the floor, Victoria will");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
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
graphics.addline(" stop and wait for you.");
graphics.textboxtimer(180);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 12:
//Intermission 1 instructional textbox, depends on last saved
obj.removetrigger(12);
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 (!obj.flags[61])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[61] = 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
graphics.textboxremovefast();
graphics.createtextbox(" You can't continue to the next ", -1, 8, 174, 174, 174);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (lastsaved == 5)
{
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
graphics.addline(" room until she is safely across. ");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
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
graphics.addline(" room until he is safely across. ");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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
graphics.textboxtimer(120);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
state = 0;
break;
case 13:
//textbox removal
obj.removetrigger(13);
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
graphics.textboxremovefast();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 14:
//Intermission 1 instructional textbox, depends on last saved
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
if (graphics.flipmode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
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
graphics.createtextbox(" When you're standing on the ceiling, ", -1, 3, 174, 174, 174);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
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
graphics.createtextbox(" When you're standing on the floor, ", -1, 3, 174, 174, 174);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if (lastsaved == 2)
{
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
graphics.addline(" Vitellary will try to walk to you. ");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 3)
{
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
graphics.addline(" Vermilion will try to walk to you. ");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 4)
{
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
graphics.addline(" Verdigris will try to walk to you. ");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 5)
{
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
graphics.addline(" Victoria will try to walk to you. ");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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
graphics.textboxtimer(280);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 15:
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//leaving the naughty corner
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[obj.getplayer()].tile = 0;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 16:
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//entering the naughty corner
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if(INBOUNDS_VEC(i, obj.entities) && obj.entities[i].tile == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].tile = 144;
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(2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
state = 0;
break;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 17:
//Arrow key tutorial
obj.removetrigger(17);
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
graphics.createtextbox(" If you prefer, you can press UP or ", -1, 195, 174, 174, 174);
graphics.addline(" DOWN instead of ACTION to flip.");
graphics.textboxtimer(100);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 20:
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 (!obj.flags[1])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[1] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(20);
break;
case 21:
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 (!obj.flags[2])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[2] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(21);
break;
case 22:
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 (!obj.flags[3])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
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
graphics.textboxremovefast();
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[3] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
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
graphics.createtextbox(" Press ACTION to flip ", -1, 25, 174, 174, 174);
graphics.textboxtimer(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(22);
break;
case 30:
//Generic "run script"
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 (!obj.flags[4])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[4] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
newscript="firststeps";
state = 0;
}
obj.removetrigger(30);
state = 0;
break;
case 31:
//state = 55; statedelay = 50;
state = 0;
statedelay = 0;
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 (!obj.flags[6])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[6] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[5] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
newscript="communicationstation";
state = 0;
statedelay = 0;
}
obj.removetrigger(31);
break;
case 32:
//Generic "run script"
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 (!obj.flags[7])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[7] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
newscript="teleporterback";
state = 0;
}
obj.removetrigger(32);
state = 0;
break;
case 33:
//Generic "run script"
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 (!obj.flags[9])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[9] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
newscript="rescueblue";
state = 0;
}
obj.removetrigger(33);
state = 0;
break;
case 34:
//Generic "run script"
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 (!obj.flags[10])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[10] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
newscript="rescueyellow";
state = 0;
}
obj.removetrigger(34);
state = 0;
break;
case 35:
//Generic "run script"
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 (!obj.flags[11])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[11] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
newscript="rescuegreen";
state = 0;
}
obj.removetrigger(35);
state = 0;
break;
case 36:
//Generic "run script"
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 (!obj.flags[8])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[8] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
newscript="rescuered";
state = 0;
}
obj.removetrigger(36);
state = 0;
break;
case 37:
//Generic "run script"
if (companion == 0)
{
startscript = true;
newscript="int2_yellow";
state = 0;
}
obj.removetrigger(37);
state = 0;
break;
case 38:
//Generic "run script"
if (companion == 0)
{
startscript = true;
newscript="int2_red";
state = 0;
}
obj.removetrigger(38);
state = 0;
break;
case 39:
//Generic "run script"
if (companion == 0)
{
startscript = true;
newscript="int2_green";
state = 0;
}
obj.removetrigger(39);
state = 0;
break;
case 40:
//Generic "run script"
if (companion == 0)
{
startscript = true;
newscript="int2_blue";
state = 0;
}
obj.removetrigger(40);
state = 0;
break;
case 41:
//Generic "run script"
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 (!obj.flags[60])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[60] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
if (lastsaved == 2)
{
newscript = "int1yellow_2";
}
else if (lastsaved == 3)
{
newscript = "int1red_2";
}
else if (lastsaved == 4)
{
newscript = "int1green_2";
}
else if (lastsaved == 5)
{
newscript = "int1blue_2";
}
state = 0;
}
obj.removetrigger(41);
state = 0;
break;
case 42:
//Generic "run script"
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 (!obj.flags[62])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[62] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
if (lastsaved == 2)
{
newscript = "int1yellow_3";
}
else if (lastsaved == 3)
{
newscript = "int1red_3";
}
else if (lastsaved == 4)
{
newscript = "int1green_3";
}
else if (lastsaved == 5)
{
newscript = "int1blue_3";
}
state = 0;
}
obj.removetrigger(42);
state = 0;
break;
case 43:
//Generic "run script"
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 (!obj.flags[63])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[63] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
if (lastsaved == 2)
{
newscript = "int1yellow_4";
}
else if (lastsaved == 3)
{
newscript = "int1red_4";
}
else if (lastsaved == 4)
{
newscript = "int1green_4";
}
else if (lastsaved == 5)
{
newscript = "int1blue_4";
}
state = 0;
}
obj.removetrigger(43);
state = 0;
break;
case 44:
//Generic "run script"
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 (!obj.flags[64])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[64] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
if (lastsaved == 2)
{
newscript = "int1yellow_5";
}
else if (lastsaved == 3)
{
newscript = "int1red_5";
}
else if (lastsaved == 4)
{
newscript = "int1green_5";
}
else if (lastsaved == 5)
{
newscript = "int1blue_5";
}
state = 0;
}
obj.removetrigger(44);
state = 0;
break;
case 45:
//Generic "run script"
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 (!obj.flags[65])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[65] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
if (lastsaved == 2)
{
newscript = "int1yellow_6";
}
else if (lastsaved == 3)
{
newscript = "int1red_6";
}
else if (lastsaved == 4)
{
newscript = "int1green_6";
}
else if (lastsaved == 5)
{
newscript = "int1blue_6";
}
state = 0;
}
obj.removetrigger(45);
state = 0;
break;
case 46:
//Generic "run script"
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 (!obj.flags[66])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[66] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
if (lastsaved == 2)
{
newscript = "int1yellow_7";
}
else if (lastsaved == 3)
{
newscript = "int1red_7";
}
else if (lastsaved == 4)
{
newscript = "int1green_7";
}
else if (lastsaved == 5)
{
newscript = "int1blue_7";
}
state = 0;
}
obj.removetrigger(46);
state = 0;
break;
case 47:
//Generic "run script"
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 (!obj.flags[69])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[69] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
newscript="trenchwarfare";
state = 0;
}
obj.removetrigger(47);
state = 0;
break;
case 48:
//Generic "run script"
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 (!obj.flags[70])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[70] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
newscript="trinketcollector";
state = 0;
}
obj.removetrigger(48);
state = 0;
break;
case 49:
//Start final level music
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 (!obj.flags[71])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[71] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.niceplay(15); //Final level remix
state = 0;
}
obj.removetrigger(49);
state = 0;
break;
case 50:
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(15);
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
graphics.createtextbox("Help! Can anyone hear", 35, 15, 255, 134, 255);
graphics.addline("this message?");
graphics.textboxtimer(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 100;
break;
case 51:
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(15);
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
graphics.createtextbox("Verdigris? Are you out", 30, 12, 255, 134, 255);
graphics.addline("there? Are you ok?");
graphics.textboxtimer(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 100;
break;
case 52:
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(15);
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
graphics.createtextbox("Please help us! We've crashed", 5, 22, 255, 134, 255);
graphics.addline("and need assistance!");
graphics.textboxtimer(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 100;
break;
case 53:
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(15);
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
graphics.createtextbox("Hello? Anyone out there?", 40, 15, 255, 134, 255);
graphics.textboxtimer(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 100;
break;
case 54:
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(15);
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
graphics.createtextbox("This is Doctor Violet from the", 5, 8, 255, 134, 255);
graphics.addline("D.S.S. Souleye! Please respond!");
graphics.textboxtimer(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 100;
break;
case 55:
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(15);
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
graphics.createtextbox("Please... Anyone...", 45, 14, 255, 134, 255);
graphics.textboxtimer(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 100;
break;
case 56:
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(15);
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
graphics.createtextbox("Please be alright, everyone...", 25, 18, 255, 134, 255);
graphics.textboxtimer(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state=50;
statedelay = 100;
break;
case 80:
//Used to return to menu from the game
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
if(graphics.fademode == 1) state++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 81:
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
2020-05-07 23:38:19 +02:00
quittomenu();
Clean up all exit paths to the menu to use common code There are multiple different exit paths to the main menu. In 2.2, they all had a bunch of copy-pasted code. In 2.3 currently, most of them use game.quittomenu(), but there are some stragglers that still use hand-copied code. This is a bit of a problem, because all exit paths should consistently have FILESYSTEM_unmountassets(), as part of the 2.3 feature of per-level custom assets. Furthermore, most (but not all) of the paths call script.hardreset() too, and some of the stragglers don't. So there could be something persisting through to the title screen (like a really long flash/shake timer) that could only persist if exiting to the title screen through those paths. But, actually, it seems like there's a good reason for some of those to not call script.hardreset() - namely, dying or completing No Death Mode and completing a Time Trial presents some information onscreen that would get reset by script.hardreset(), so I'll fix that in a later commit. So what I've done for this commit is found every exit path that didn't already use game.quittomenu(), and made them use game.quittomenu(). As well, some of them had special handling that existed on top of them already having a corresponding entry in game.quittomenu() (but the path would take the special handling because it never did game.quittomenu()), so I removed that special handling as well (e.g. exiting from a custom level used returntomenu(Menu::levellist) when quittomenu() already had that same returntomenu()). The menu that exiting from the level editor returns to is now handled in game.quittomenu() as well, where the map.custommode branch now also checks for map.custommodeforreal. Unfortunately, it seems like entering the level editor doesn't properly initialize map.custommode, so entering the level editor now initializes map.custommode, too. I've also taken the music.play(6) out of game.quittomenu(), because not all exit paths immediately play Presenting VVVVVV, so all exit paths that DO immediately play Presenting VVVVVV now have music.play(6) special-cased for them, which is fine enough for me. Here is the list of all exit paths to the menu: - Exiting through the pause menu (without glitchrunner mode) - Exiting through the pause menu (with glitchrunner mode) - Completing a custom level - Completing a Time Trial - Dying in No Death Mode - Completing No Death Mode - Completing an Intermission replay - Exiting from the level editor - Completing the main game
2021-01-07 23:20:37 +01:00
music.play(6); //should be after quittomenu()
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 82:
//Time Trial Complete!
obj.removetrigger(82);
hascontrol = false;
Fix Time Trial results being reset before being shown This makes it so when a Time Trial gets completed, all the relevant variables get copied onto variables prefixed with 'timetrialresult', which never get reset by script.hardreset(). Then titlerender() will use those variables accordingly.
2021-01-08 01:02:45 +01:00
Account for hours when calculating time trial result time This prevents being able to "roll over" the amount of minutes to 0 (by simply waiting for the timer to tick past one hour) and being able to get a result of 00:13 when your result is really 01:00:13. By looking only at the minutes, the game would read 01:00:13 as 00:13 instead. So simply add the amount of hours to the time trial result.
2020-06-18 07:58:44 +02:00
timetrialresulttime = seconds + (minutes * 60) + (hours * 60 * 60);
Display centiseconds on time trial result and Game Complete Centiseconds won't be saved to any save file or anything. This is just to make speedrunning a bit more competitive, being able to know the precise time of a time trial or full game run. The time trial par time on the result screen always has ".99" after it. This is basically due to the game comparing the number of seconds to the par number of seconds using less-than-or-equal-to instead of simply less-than.
2020-06-30 00:53:19 +02:00
timetrialresultframes = frames;
Fix Time Trial results being reset before being shown This makes it so when a Time Trial gets completed, all the relevant variables get copied onto variables prefixed with 'timetrialresult', which never get reset by script.hardreset(). Then titlerender() will use those variables accordingly.
2021-01-08 01:02:45 +01:00
timetrialresulttrinkets = trinkets();
timetrialresultshinytarget = timetrialshinytarget;
timetrialresultpar = timetrialpar;
timetrialresultdeaths = deathcounts;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
timetrialrank = 0;
if (timetrialresulttime <= timetrialpar) timetrialrank++;
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
if (trinkets() >= timetrialshinytarget) timetrialrank++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (deathcounts == 0) timetrialrank++;
Read and write best time trial frames This is basically just bolting on the "frames" part of a time trial score. There's not enough space to properly show it on the time trial select screen, maybe we can figure something out later. But I at least want to implement the functionality now.
2020-07-01 03:59:16 +02:00
if (timetrialresulttime < besttimes[timetriallevel]
|| (timetrialresulttime == besttimes[timetriallevel] && timetrialresultframes < bestframes[timetriallevel])
|| besttimes[timetriallevel]==-1)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
besttimes[timetriallevel] = timetrialresulttime;
Read and write best time trial frames This is basically just bolting on the "frames" part of a time trial score. There's not enough space to properly show it on the time trial select screen, maybe we can figure something out later. But I at least want to implement the functionality now.
2020-07-01 03:59:16 +02:00
bestframes[timetriallevel] = timetrialresultframes;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Fix Time Trial results being reset before being shown This makes it so when a Time Trial gets completed, all the relevant variables get copied onto variables prefixed with 'timetrialresult', which never get reset by script.hardreset(). Then titlerender() will use those variables accordingly.
2021-01-08 01:02:45 +01:00
if (timetrialresulttrinkets > besttrinkets[timetriallevel] || besttrinkets[timetriallevel]==-1)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
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
besttrinkets[timetriallevel] = trinkets();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if (deathcounts < bestlives[timetriallevel] || bestlives[timetriallevel]==-1)
{
bestlives[timetriallevel] = deathcounts;
}
if (timetrialrank > bestrank[timetriallevel] || bestrank[timetriallevel]==-1)
{
bestrank[timetriallevel] = timetrialrank;
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
if(timetrialrank>=3){
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
if(timetriallevel==0) unlockAchievement("vvvvvvtimetrial_station1_fixed");
if(timetriallevel==1) unlockAchievement("vvvvvvtimetrial_lab_fixed");
if(timetriallevel==2) unlockAchievement("vvvvvvtimetrial_tower_fixed");
if(timetriallevel==3) unlockAchievement("vvvvvvtimetrial_station2_fixed");
if(timetriallevel==4) unlockAchievement("vvvvvvtimetrial_warp_fixed");
if(timetriallevel==5) unlockAchievement("vvvvvvtimetrial_final_fixed");
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
savestatsandsettings();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.fadeout();
state++;
break;
case 83:
frames--;
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
if(graphics.fademode == 1) state++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 84:
Clean up all exit paths to the menu to use common code There are multiple different exit paths to the main menu. In 2.2, they all had a bunch of copy-pasted code. In 2.3 currently, most of them use game.quittomenu(), but there are some stragglers that still use hand-copied code. This is a bit of a problem, because all exit paths should consistently have FILESYSTEM_unmountassets(), as part of the 2.3 feature of per-level custom assets. Furthermore, most (but not all) of the paths call script.hardreset() too, and some of the stragglers don't. So there could be something persisting through to the title screen (like a really long flash/shake timer) that could only persist if exiting to the title screen through those paths. But, actually, it seems like there's a good reason for some of those to not call script.hardreset() - namely, dying or completing No Death Mode and completing a Time Trial presents some information onscreen that would get reset by script.hardreset(), so I'll fix that in a later commit. So what I've done for this commit is found every exit path that didn't already use game.quittomenu(), and made them use game.quittomenu(). As well, some of them had special handling that existed on top of them already having a corresponding entry in game.quittomenu() (but the path would take the special handling because it never did game.quittomenu()), so I removed that special handling as well (e.g. exiting from a custom level used returntomenu(Menu::levellist) when quittomenu() already had that same returntomenu()). The menu that exiting from the level editor returns to is now handled in game.quittomenu() as well, where the map.custommode branch now also checks for map.custommodeforreal. Unfortunately, it seems like entering the level editor doesn't properly initialize map.custommode, so entering the level editor now initializes map.custommode, too. I've also taken the music.play(6) out of game.quittomenu(), because not all exit paths immediately play Presenting VVVVVV, so all exit paths that DO immediately play Presenting VVVVVV now have music.play(6) special-cased for them, which is fine enough for me. Here is the list of all exit paths to the menu: - Exiting through the pause menu (without glitchrunner mode) - Exiting through the pause menu (with glitchrunner mode) - Completing a custom level - Completing a Time Trial - Dying in No Death Mode - Completing No Death Mode - Completing an Intermission replay - Exiting from the level editor - Completing the main game
2021-01-07 23:20:37 +01:00
quittomenu();
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
createmenu(Menu::timetrialcomplete);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 85:
//Cutscene skip version of final level change
obj.removetrigger(85);
//Init final stretch
state++;
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(9);
Revert "Change final stretch song to Piercing the Sky" Upon further discussion it was decided to keep the soundtrack as originally shipped, instead of changing it after the fact. This reverts commit cf51379097d8b80f4550d6fdb345577b452f6740.
2021-05-21 05:01:43 +02:00
music.play(2);
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[72] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
screenshake = 10;
flashlight = 5;
map.finalstretch = true;
map.warpx = false;
map.warpy = false;
map.background = 6;
map.final_colormode = true;
map.final_colorframe = 1;
state = 0;
break;
//From 90-100 are run scripts for the eurogamer expo only, remove later
case 90:
//Generic "run script"
startscript = true;
newscript="startexpolevel_station1";
obj.removetrigger(90);
state = 0;
break;
case 91:
//Generic "run script"
startscript = true;
newscript="startexpolevel_lab";
obj.removetrigger(91);
state = 0;
break;
case 92:
//Generic "run script"
startscript = true;
newscript="startexpolevel_warp";
obj.removetrigger(92);
state = 0;
break;
case 93:
//Generic "run script"
startscript = true;
newscript="startexpolevel_tower";
obj.removetrigger(93);
state = 0;
break;
case 94:
//Generic "run script"
startscript = true;
newscript="startexpolevel_station2";
obj.removetrigger(94);
state = 0;
break;
case 95:
//Generic "run script"
startscript = true;
newscript="startexpolevel_final";
obj.removetrigger(95);
state = 0;
break;
case 96:
//Used to return to gravitron to game
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
if(graphics.fademode == 1) state++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 97:
Move return to lab code to Game::returntolab() Again, I'll keep gamestate 96 and 97 for compatibility reasons, but ultimately we shouldn't be using gamestates to return to the lab.
2020-05-08 00:17:04 +02:00
returntolab();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 100:
//
// Meeting crewmate in the warpzone
//
obj.removetrigger(100);
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 (!obj.flags[4])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[4] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
}
break;
case 101:
{
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = false;
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities) && obj.entities[i].onroof > 0 && gravitycontrol == 1)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
gravitycontrol = 0;
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
}
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities) && obj.entities[i].onground > 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
state++;
}
}
break;
case 102:
{
companion = 6;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[i].tile = 0;
obj.entities[i].state = 1;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
advancetext = true;
hascontrol = false;
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
graphics.createtextbox("Captain! I've been so worried!", 60, 90, 164, 255, 164);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(12);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 104:
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
graphics.createtextbox("I'm glad you're ok!", 135, 152, 164, 164, 255);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(11);
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
graphics.textboxactive();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 106:
{
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
graphics.createtextbox("I've been trying to find a", 74, 70, 164, 255, 164);
graphics.addline("way out, but I keep going");
graphics.addline("around in circles...");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(2);
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
graphics.textboxactive();
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[i].tile = 54;
obj.entities[i].state = 0;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 108:
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
graphics.createtextbox("Don't worry! I have a", 125, 152, 164, 164, 255);
graphics.addline("teleporter key!");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(11);
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
graphics.textboxactive();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 110:
{
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[i].tile = 0;
obj.entities[i].state = 1;
}
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
graphics.createtextbox("Follow me!", 185, 154, 164, 164, 255);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(11);
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
graphics.textboxactive();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 112:
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = true;
advancetext = false;
state = 0;
break;
case 115:
//
// Test script for space station, totally delete me!
//
hascontrol = false;
state++;
break;
case 116:
advancetext = true;
hascontrol = false;
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
graphics.createtextbox("Sorry Eurogamers! Teleporting around", 60 - 20, 200, 255, 64, 64);
graphics.addline("the map doesn't work in this version!");
graphics.textboxcenterx();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
break;
case 118:
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = true;
advancetext = false;
state = 0;
break;
case 120:
//
// Meeting crewmate in the space station
//
obj.removetrigger(120);
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 (!obj.flags[5])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use obj.changeflag() to set flags The way I see it, that function is basically an unnecessary middleman.
2020-04-09 08:46:41 +02:00
obj.flags[5] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
}
break;
case 121:
{
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = false;
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities) && obj.entities[i].onground > 0 && gravitycontrol == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
gravitycontrol = 1;
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
}
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities) && obj.entities[i].onroof > 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
state++;
}
}
break;
case 122:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
companion = 7;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[i].tile = 6;
obj.entities[i].state = 1;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
advancetext = true;
hascontrol = false;
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
graphics.createtextbox("Captain! You're ok!", 60-10, 90-40, 255, 255, 134);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(14);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 124:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
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
graphics.createtextbox("I've found a teleporter, but", 60-20, 90 - 40, 255, 255, 134);
graphics.addline("I can't get it to go anywhere...");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(2);
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
graphics.textboxactive();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 126:
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
graphics.createtextbox("I can help with that!", 125, 152-40, 164, 164, 255);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(11);
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
graphics.textboxactive();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 128:
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
graphics.createtextbox("I have the teleporter", 130, 152-35, 164, 164, 255);
graphics.addline("codex for our ship!");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(11);
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
graphics.textboxactive();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 130:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
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
graphics.createtextbox("Yey! Let's go home!", 60-30, 90-35, 255, 255, 134);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(14);
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
graphics.textboxactive();
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[i].tile = 6;
obj.entities[i].state = 1;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 132:
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = true;
advancetext = false;
state = 0;
break;
case 200:
//Init final stretch
state++;
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(9);
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[72] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
screenshake = 10;
flashlight = 5;
map.finalstretch = true;
map.warpx = false;
map.warpy = false;
map.background = 6;
map.final_colormode = true;
map.final_colorframe = 1;
startscript = true;
newscript="finalterminal_finish";
state = 0;
break;
Fix the two-frame-delay when entering a room with an "init" script This patch is very kludge-y, but at least it fixes a semi-noticeable visual issue in custom levels that use internal scripts to spawn entities when loading a room. Basically, the problem here is that when the game checks for script boxes and sets newscript, newscript has already been processed for that frame, and when the game does load a script, script.run() has already been processed for that frame. That issue can be fixed, but it turns out that due to my over-30-FPS game loop changes, there's now ANOTHER visible frame of delay between room load and entity creation, because the render function gets called in between the script being loaded at the end of gamelogic() and the script actually getting run. So... I have to temporary move script.run() to the end of gamelogic() (in map.twoframedelayfix()), and make sure it doesn't get run next frame, because double-evaluations are bad. To do that, I have to introduce the kludge variable script.dontrunnextframe, which does exactly as it says. And with all that work, the two-frame (now three-frame) delay is fixed.
2020-06-28 02:08:57 +02:00
// WARNING: If updating this code, make sure to update Map.cpp mapclass::twoframedelayfix()
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 300:
case 301:
case 302:
case 303:
case 304:
case 305:
case 306:
case 307:
case 308:
case 309:
case 310:
case 311:
case 312:
case 313:
case 314:
case 315:
case 316:
case 317:
case 318:
case 319:
case 320:
case 321:
case 322:
case 323:
case 324:
case 325:
case 326:
case 327:
case 328:
case 329:
case 330:
case 331:
case 332:
case 333:
case 334:
case 335:
case 336:
startscript = true;
De-duplicate gamestates 300..336 Gamestates 300..336 are used to start scripts in custom levels. However, it looks like instead of having the cases have common code, each individual case was copy-pasted numerous times, which is pretty wasteful.
2020-07-10 03:14:18 +02:00
newscript="custom_"+customscript[state - 300];
obj.removetrigger(state);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 1000:
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
graphics.showcutscenebars = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = false;
completestop = true;
state++;
statedelay = 15;
break;
case 1001:
//Found a trinket!
advancetext = true;
state++;
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme(" Congratulations! ", 50, 85, 174, 174, 174);
graphics.addline("");
graphics.addline("You have found a shiny trinket!");
graphics.textboxcenterx();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove map.customtrinkets This variable's sole purpose is to copy ed.numtrinkets, even though ed has always been a name that's been accessible globally. So let's not dupe cope.
2020-04-09 06:56:47 +02:00
#if !defined(NO_CUSTOM_LEVELS)
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
if(map.custommode)
{
graphics.createtextboxflipme(" " + help.number(trinkets()) + " out of " + help.number(ed.numtrinkets())+ " ", 50, 135, 174, 174, 174);
graphics.textboxcenterx();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme(" " + help.number(trinkets()) + " out of Twenty ", 50, 135, 174, 174, 174);
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
graphics.textboxcenterx();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
Fix softlock from interrupted completestop In summary, if you got to gamestate 1002 or 1012 without an advancetext, and you had completestop on, you were basically softlocked. So just add those gamestates there and advance the gamestate if advancetext is off.
2020-07-05 07:55:21 +02:00
case 1002:
if (!advancetext)
{
// Prevent softlocks if we somehow don't have advancetext
state++;
}
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 1003:
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = true;
advancetext = false;
completestop = false;
state = 0;
if(!muted && music.currentsong>-1) music.fadeMusicVolumeIn(3000);
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
graphics.showcutscenebars = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 1010:
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
graphics.showcutscenebars = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = false;
completestop = true;
state++;
statedelay = 15;
break;
Remove map.customcrewmates Same as the previous commit, except for the amount of custom crewmates.
2020-04-09 07:01:32 +02:00
#if !defined(NO_CUSTOM_LEVELS)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 1011:
Fix crewmate-found text boxes overlapping in flip mode The problem was that the code seemed to be wrongly copy-pasted from the code for generating the trinket-found text boxes (to the point where even the comment for the crewmate-found text boxes didn't get changed from "//Found a trinket!"). For the trinket-found text boxes, they use y-positions 85 and 135 if not in flip mode, and y-positions 105 and 65 if the game IS in flip mode. These text boxes are positioned correctly in flip mode. However, for the crewmate-found text boxes, they use y-positions 85 and 135 if not in flip mode, as usual, but they use y-positions 105 and 135 if the game IS in flip mode. Looks like someone forgot to change the second y-position when copy-pasting code around. Which is actually a bit funny, because I can conclude from this that it seems like the code to position these text boxes in flip mode was bolted-on AFTER the initial code of these text boxes was written. I can also conclude (hot take incoming) that basically no one actually ever tested this game in flip mode (but that was already evident, given TerryCavanagh/VVVVVV#140, less strongly TerryCavanagh/VVVVVV#141, and TerryCavanagh/VVVVVV#142 is another flip-mode-related bug which I guess sorta kinda doesn't really count since text outline wasn't enabled until 2.3?). So I fixed the second y-position to be 65, just like the y-position the trinket text boxes use. I even took the opportunity to fix the comment to say "//Found a crewmate!" instead of "//Found a trinket!".
2020-02-16 07:58:42 +01:00
//Found a crewmate!
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
advancetext = true;
state++;
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme(" Congratulations! ", 50, 85, 174, 174, 174);
graphics.addline("");
graphics.addline("You have found a lost crewmate!");
graphics.textboxcenterx();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
if(ed.numcrewmates()-crewmates()==0)
{
graphics.createtextboxflipme(" All crewmates rescued! ", 50, 135, 174, 174, 174);
}
else if(ed.numcrewmates()-crewmates()==1)
{
graphics.createtextboxflipme(" " + help.number(ed.numcrewmates()-crewmates())+ " remains ", 50, 135, 174, 174, 174);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme(" " + help.number(ed.numcrewmates()-crewmates())+ " remain ", 50, 135, 174, 174, 174);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.textboxcenterx();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Fix softlock from interrupted completestop In summary, if you got to gamestate 1002 or 1012 without an advancetext, and you had completestop on, you were basically softlocked. So just add those gamestates there and advance the gamestate if advancetext is off.
2020-07-05 07:55:21 +02:00
case 1012:
if (!advancetext)
{
// Prevent softlocks if we somehow don't have advancetext
state++;
}
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 1013:
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = true;
advancetext = false;
completestop = false;
state = 0;
Don't use separate variable for number of crewmates in level Same as previous commit, this time for crewmates.
2020-04-09 07:13:43 +02:00
if(ed.numcrewmates()-crewmates()==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if(map.custommodeforreal)
{
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
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if(!muted && ed.levmusic>0) music.fadeMusicVolumeIn(3000);
if(ed.levmusic>0) music.fadeout();
state=1014;
}
else
{
Remove game.shouldreturntoeditor in favor of using defer callback game.shouldreturntoeditor was added to fix a frame ordering issue that was causing a bug where if you started playtesting in a room with a horizontal/vertical warp background, and exited playtesting in a different room that also had a horizontal/vertical warp background and which was different, then the background of the room you exited in would slowly scroll offscreen, when you re-entered the editor, instead of the background consisting entirely of the actual background of the room. Namely, the issue was that the game would render one more frame of GAMEMODE after graphics.backgrounddrawn got set to false, and re-set it to true, thus negating the background redraw, so the editor background would be incorrect. With defer callbacks, we can now just use a couple lines of code, instead of having to add an extra kludge variable and putting handling for it all over the code.
2021-01-10 23:48:25 +01:00
returntoeditor();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if(!muted && ed.levmusic>0) music.fadeMusicVolumeIn(3000);
if(ed.levmusic>0) music.fadeout();
}
}
else
{
if(!muted && ed.levmusic>0) music.fadeMusicVolumeIn(3000);
}
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
graphics.showcutscenebars = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
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
case 1014:
frames--;
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
if(graphics.fademode == 1) state++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 1015:
Remove map.customcrewmates Same as the previous commit, except for the amount of custom crewmates.
2020-04-09 07:01:32 +02:00
#if !defined(NO_CUSTOM_LEVELS)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Update level stats
Don't use separate variable for number of crewmates in level Same as previous commit, this time for crewmates.
2020-04-09 07:13:43 +02:00
if(ed.numcrewmates()-crewmates()==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Finished level
Don't use separate variable for number of trinkets in level Same principle as removing the separate variable to track number of collected trinkets. This means it's less error-prone as we're no longer tracking number of trinkets separately. In the function that counts the number of trinkets, I would've liked to have used std::count_if(). However, the most optimal way would require using a lambda, and lambdas are too new for the C++ standard we're using. So I just bit the bullet and counted them manually.
2020-04-09 07:09:11 +02:00
if(ed.numtrinkets()-trinkets()==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//and got all the trinkets!
updatecustomlevelstats(customlevelfilename, 3);
}
else
{
updatecustomlevelstats(customlevelfilename, 1);
}
}
Remove map.customcrewmates Same as the previous commit, except for the amount of custom crewmates.
2020-04-09 07:01:32 +02:00
#endif
replace stray tab with spaces whoops, recently reinstalled windows so my editor settings still arent perfect yet
2020-08-01 22:01:58 +02:00
quittomenu();
Clean up all exit paths to the menu to use common code There are multiple different exit paths to the main menu. In 2.2, they all had a bunch of copy-pasted code. In 2.3 currently, most of them use game.quittomenu(), but there are some stragglers that still use hand-copied code. This is a bit of a problem, because all exit paths should consistently have FILESYSTEM_unmountassets(), as part of the 2.3 feature of per-level custom assets. Furthermore, most (but not all) of the paths call script.hardreset() too, and some of the stragglers don't. So there could be something persisting through to the title screen (like a really long flash/shake timer) that could only persist if exiting to the title screen through those paths. But, actually, it seems like there's a good reason for some of those to not call script.hardreset() - namely, dying or completing No Death Mode and completing a Time Trial presents some information onscreen that would get reset by script.hardreset(), so I'll fix that in a later commit. So what I've done for this commit is found every exit path that didn't already use game.quittomenu(), and made them use game.quittomenu(). As well, some of them had special handling that existed on top of them already having a corresponding entry in game.quittomenu() (but the path would take the special handling because it never did game.quittomenu()), so I removed that special handling as well (e.g. exiting from a custom level used returntomenu(Menu::levellist) when quittomenu() already had that same returntomenu()). The menu that exiting from the level editor returns to is now handled in game.quittomenu() as well, where the map.custommode branch now also checks for map.custommodeforreal. Unfortunately, it seems like entering the level editor doesn't properly initialize map.custommode, so entering the level editor now initializes map.custommode, too. I've also taken the music.play(6) out of game.quittomenu(), because not all exit paths immediately play Presenting VVVVVV, so all exit paths that DO immediately play Presenting VVVVVV now have music.play(6) special-cased for them, which is fine enough for me. Here is the list of all exit paths to the menu: - Exiting through the pause menu (without glitchrunner mode) - Exiting through the pause menu (with glitchrunner mode) - Completing a custom level - Completing a Time Trial - Dying in No Death Mode - Completing No Death Mode - Completing an Intermission replay - Exiting from the level editor - Completing the main game
2021-01-07 23:20:37 +01:00
music.play(6); //should be after quittomenu()
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 2000:
//Game Saved!
De-duplicate "Game Saved" telesave textbox The "Game Saved" text box, along with its associated telesave() call, exists in both Game.cpp and Script.cpp, so one of them is the copy-paste of the other. Unfortunately this copy-paste resulted in an inconsistency where both of them don't check for the same things when deciding whether or not the telesave should actually happen (this is why you don't copy-paste, kids... it's scary!). Either way, de-duplicating this now is less work for me later.
2021-03-20 03:40:16 +01:00
savetele_textbox();
state = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 2500:
music.play(5);
//Activating a teleporter (appear)
state++;
statedelay = 15;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 2501:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
//we're done here!
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 2502:
Guard all cases obj.getteleporter() is used unchecked obj.getteleporter() is able to return -1. If there's no check on it, it will end up indexing out-of-bounds, which is Undefined Behavior.
2020-06-13 04:31:08 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 5;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getteleporter() is used unchecked obj.getteleporter() is able to return -1. If there's no check on it, it will end up indexing out-of-bounds, which is Undefined Behavior.
2020-06-13 04:31:08 +02:00
{
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].colour = 0;
obj.entities[i].invis = false;
int j = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = obj.entities[j].xp+44;
obj.entities[i].yp = obj.entities[j].yp+44;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp = obj.entities[i].xp;
obj.entities[i].lerpoldyp = obj.entities[i].yp;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
}
obj.entities[i].ay = -6;
obj.entities[i].ax = 6;
obj.entities[i].vy = -6;
obj.entities[i].vx = 6;
Guard all cases obj.getteleporter() is used unchecked obj.getteleporter() is able to return -1. If there's no check on it, it will end up indexing out-of-bounds, which is Undefined Behavior.
2020-06-13 04:31:08 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
i = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getteleporter() is used unchecked obj.getteleporter() is able to return -1. If there's no check on it, it will end up indexing out-of-bounds, which is Undefined Behavior.
2020-06-13 04:31:08 +02:00
{
obj.entities[i].tile = 1;
obj.entities[i].colour = 101;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Guard all cases obj.getteleporter() is used unchecked obj.getteleporter() is able to return -1. If there's no check on it, it will end up indexing out-of-bounds, which is Undefined Behavior.
2020-06-13 04:31:08 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 2503:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 2504:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
//obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 2505:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 2506:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 2507:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 2508:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 2;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 2509:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 15;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 1;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 2510:
advancetext = true;
hascontrol = false;
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
graphics.createtextbox("Hello?", 125+24, 152-20, 164, 164, 255);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(11);
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
graphics.textboxactive();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 2512:
advancetext = true;
hascontrol = false;
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
graphics.createtextbox("Is anyone there?", 125+8, 152-24, 164, 164, 255);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
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(11);
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
graphics.textboxactive();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 2514:
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
hascontrol = true;
advancetext = false;
state = 0;
music.play(3);
break;
case 3000:
//Activating a teleporter (long version for level complete)
state++;
statedelay = 30;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3001:
//Activating a teleporter 2
state++;
statedelay = 15;
flashlight = 5;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3002:
//Activating a teleporter 2
state++;
statedelay = 15;
flashlight = 5;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3003:
//Activating a teleporter 2
state++;
statedelay = 15;
flashlight = 5;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3004:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
//we're done here!
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3005:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 50;
switch(companion)
{
case 6:
state = 3006;
break; //Warp Zone
case 7:
state = 3020;
break; //Space Station
case 8:
state = 3040;
break; //Lab
case 9:
state = 3060;
break; //Tower
case 10:
state = 3080;
break; //Intermission 2
case 11:
state = 3085;
break; //Intermission 1
}
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].colour = 0;
obj.entities[i].invis = true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
i = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if(INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix entity and block indices after destroying them This patch restores some 2.2 behavior, fixing a regression caused by the refactor of properly using std::vectors. In 2.2, the game allocated 200 items in obj.entities, but used a system where each entity had an `active` attribute to signify if the entity actually existed or not. When dealing with entities, you would have to check this `active` flag, or else you'd be dealing with an entity that didn't actually exist. (By the way, what I'm saying applies to blocks and obj.blocks as well, except for some small differing details like the game allocating 500 block slots versus obj.entities's 200.) As a consequence, the game had to use a separate tracking variable, obj.nentity, because obj.entities.size() would just report 200, instead of the actual amount of entities. Needless to say, having to check for `active` and use `obj.nentity` is a bit error-prone, and it's messier than simply using the std::vector the way it was intended. Also, this resulted in a hard limit of 200 entities, which custom level makers ran into surprisingly quite often. 2.3 comes along, and removes the whole system. Now, std::vectors are properly being used, and obj.entities.size() reports the actual number of entities in the vector; you no longer have to check for `active` when dealing with entities of any sort. But there was one previous behavior of 2.2 that this system kind of forgets about - namely, the ability to have holes in between entities. You see, when an entity got disabled in 2.2 (which just meant turning its `active` off), the indices of all other entities stayed the same; the indice of the entity that got disabled stays there as a hole in the array. But when an entity gets removed in 2.3 (previous to this patch), the indices of every entity afterwards in the array get shifted down by one. std::vector isn't really meant to be able to contain holes. Do the indices of entities and blocks matter? Yes; they determine the order in which entities and blocks get evaluated (the highest indice gets evaluated first), and I had to fix some block evaluation order stuff in previous PRs. And in the case of entities, they matter hugely when using the recently-discovered Arbitrary Entity Manipulation glitch (where crewmate script commands are used on arbitrary entities by setting the `i` attribute of `scriptclass` and passing invalid crewmate identifiers to the commands). If you use Arbitrary Entity Manipulation after destroying some entities, there is a chance that your script won't work between 2.2 and 2.3. The indices also still determine the rendering order of entities (highest indice gets drawn first, which means lowest indice gets drawn in front of other entities). As an example: let's say we have the player at 0, a gravity line at 1, and a checkpoint at 2; then we destroy the gravity line and create a crewmate (let's do Violet). If we're able to have holes, then after removing the gravity line, none of the other indices shift. Then Violet will be created at indice 1, and will be drawn in front of the checkpoint. But if we can't have holes, then removing the gravity line results in the indice of the checkpoint shifting down to indice 1. Then Violet is created at indice 2, and gets drawn behind the checkpoint! This is a clear illustration of changing the behavior that existed in 2.2. However, I also don't want to go back to the `active` system of having to check an attribute before operating on an entity. So... what do we do to restore the holes? Well, we don't need to have an `active` attribute, or modify any existing code that operates on entities. Instead, we can just set the attributes of the entities so that they naturally get ignored by everything that comes into contact with it. For entities, we set their invis to true, and their size, type, and rule to -1 (the game never uses a size, type, or rule of -1 anywhere); for blocks, we set their type to -1, and their width and height to 0. obj.entities.size() will no longer necessarily equal the amount of entities in the room; rather, it will be the amount of entity SLOTS that have been allocated. But nothing that uses obj.entities.size() needs to actually know the amount of entities; it's mostly used for iterating over every entity in the vector. Excess entity slots get cleaned up upon every call of mapclass::gotoroom(), which will now deallocate entity slots starting from the end until it hits a player, at which point it will switch to disabling entity slots instead of removing them entirely. The entclass::clear() and blockclass::clear() functions have been restored because we need to call their initialization functions when reusing a block/entity slot; it's possible to create an entity with an invalid type number (it creates a glitchy Viridian), and without calling the initialization function again, it would simply not create anything. After this patch is applied, entity and block indices will be restored to how they behaved in 2.2.
2020-12-27 07:11:34 +01:00
obj.disableentity(i);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
i = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getteleporter() is used unchecked obj.getteleporter() is able to return -1. If there's no check on it, it will end up indexing out-of-bounds, which is Undefined Behavior.
2020-06-13 04:31:08 +02:00
{
obj.entities[i].tile = 1;
obj.entities[i].colour = 100;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 3006:
//Level complete! (warp zone)
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
unlocknum(4);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
lastsaved = 4;
music.play(0);
state++;
statedelay = 75;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
levelcomplete_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3007:
state++;
statedelay = 45;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
crewmate_textbox(175, 174, 174);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3008:
state++;
statedelay = 45;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
remaining_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3009:
state++;
statedelay = 0;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3010:
if (jumppressed)
{
state++;
statedelay = 30;
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 3011:
state = 3070;
statedelay = 0;
break;
case 3020:
//Level complete! (Space Station 2)
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
unlocknum(3);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
lastsaved = 2;
music.play(0);
state++;
statedelay = 75;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
levelcomplete_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3021:
state++;
statedelay = 45;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
crewmate_textbox(174, 175, 174);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3022:
state++;
statedelay = 45;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
remaining_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3023:
state++;
statedelay = 0;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3024:
if (jumppressed)
{
state++;
statedelay = 30;
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 3025:
state = 3070;
statedelay = 0;
break;
case 3040:
//Level complete! (Lab)
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
unlocknum(1);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
lastsaved = 5;
music.play(0);
state++;
statedelay = 75;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
levelcomplete_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3041:
state++;
statedelay = 45;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
crewmate_textbox(174, 174, 175);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3042:
state++;
statedelay = 45;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
remaining_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3043:
state++;
statedelay = 0;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3044:
if (jumppressed)
{
state++;
statedelay = 30;
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 3045:
state = 3070;
statedelay = 0;
break;
case 3050:
//Level complete! (Space Station 1)
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
unlocknum(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
lastsaved = 1;
music.play(0);
state++;
statedelay = 75;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
levelcomplete_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3051:
state++;
statedelay = 45;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
crewmate_textbox(175, 175, 174);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3052:
state++;
statedelay = 45;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
remaining_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3053:
state++;
statedelay = 0;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3054:
if (jumppressed)
{
state++;
statedelay = 30;
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
teleportscript = "";
}
break;
case 3055:
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
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 10;
break;
case 3056:
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
if(graphics.fademode==1)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
startscript = true;
Fix unwinnable save from rescuing Violet out of order You're intended to rescue Violet first, and not second, third, or fourth, and especially not last. If you rescue her second, third, or fourth, your crewmate progress will be reset, but you won't be able to re-rescue them again. This is because Vitellary, Verdigris, Victoria, and Vermilion will be temporarily marked as rescued during the `bigopenworld` cutscene, so duplicate versions of them don't spawn during the cutscene, and then will be marked as missing later to undo it. This first issue can be trivially fixed by simply toggling flags to prevent duplicates of them from spawning during the cutscene instead of fiddling with their rescue statuses. However, there is still another issue. If you rescue Violet last, then you won't be warped to the Final Level, meaning you can't properly complete the game. This can be fixed by adding a `crewrescued() == 6` check to the Space Station 1 Level Complete cutscene. There is additionally a temporary unrescuing of Violet so she doesn't get duplicated during the `bigopenworld` cutscene, and I've had to move that to the start of the `bigopenworld` and `bigopenworldskip` scripts, otherwise the `crewrescued() == 6` check won't work properly. I haven't added hooks for Intermission 1 or 2 because you're not really meant to play the intermissions with Violet (but you probably could anyway, there'd just be no dialogue). Oh, and the pre-Final Level cutscene expects the player to already be hidden before it starts playing, but if you rescue Violet last the player is still visible, so I've fixed that. But there still ends up being two Violets, so I'll probably replace it with a special cutscene later that's not so nonsensical.
2020-08-09 01:09:55 +02:00
if (crewrescued() == 6)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix unwinnable save from rescuing Violet out of order You're intended to rescue Violet first, and not second, third, or fourth, and especially not last. If you rescue her second, third, or fourth, your crewmate progress will be reset, but you won't be able to re-rescue them again. This is because Vitellary, Verdigris, Victoria, and Vermilion will be temporarily marked as rescued during the `bigopenworld` cutscene, so duplicate versions of them don't spawn during the cutscene, and then will be marked as missing later to undo it. This first issue can be trivially fixed by simply toggling flags to prevent duplicates of them from spawning during the cutscene instead of fiddling with their rescue statuses. However, there is still another issue. If you rescue Violet last, then you won't be warped to the Final Level, meaning you can't properly complete the game. This can be fixed by adding a `crewrescued() == 6` check to the Space Station 1 Level Complete cutscene. There is additionally a temporary unrescuing of Violet so she doesn't get duplicated during the `bigopenworld` cutscene, and I've had to move that to the start of the `bigopenworld` and `bigopenworldskip` scripts, otherwise the `crewrescued() == 6` check won't work properly. I haven't added hooks for Intermission 1 or 2 because you're not really meant to play the intermissions with Violet (but you probably could anyway, there'd just be no dialogue). Oh, and the pre-Final Level cutscene expects the player to already be hidden before it starts playing, but if you rescue Violet last the player is still visible, so I've fixed that. But there still ends up being two Violets, so I'll probably replace it with a special cutscene later that's not so nonsensical.
2020-08-09 01:09:55 +02:00
newscript = "startlevel_final";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Fix unwinnable save from rescuing Violet out of order You're intended to rescue Violet first, and not second, third, or fourth, and especially not last. If you rescue her second, third, or fourth, your crewmate progress will be reset, but you won't be able to re-rescue them again. This is because Vitellary, Verdigris, Victoria, and Vermilion will be temporarily marked as rescued during the `bigopenworld` cutscene, so duplicate versions of them don't spawn during the cutscene, and then will be marked as missing later to undo it. This first issue can be trivially fixed by simply toggling flags to prevent duplicates of them from spawning during the cutscene instead of fiddling with their rescue statuses. However, there is still another issue. If you rescue Violet last, then you won't be warped to the Final Level, meaning you can't properly complete the game. This can be fixed by adding a `crewrescued() == 6` check to the Space Station 1 Level Complete cutscene. There is additionally a temporary unrescuing of Violet so she doesn't get duplicated during the `bigopenworld` cutscene, and I've had to move that to the start of the `bigopenworld` and `bigopenworldskip` scripts, otherwise the `crewrescued() == 6` check won't work properly. I haven't added hooks for Intermission 1 or 2 because you're not really meant to play the intermissions with Violet (but you probably could anyway, there'd just be no dialogue). Oh, and the pre-Final Level cutscene expects the player to already be hidden before it starts playing, but if you rescue Violet last the player is still visible, so I've fixed that. But there still ends up being two Violets, so I'll probably replace it with a special cutscene later that's not so nonsensical.
2020-08-09 01:09:55 +02:00
if (nocutscenes)
{
newscript="bigopenworldskip";
}
else
{
newscript = "bigopenworld";
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
state = 0;
}
break;
case 3060:
//Level complete! (Tower)
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
unlocknum(2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
lastsaved = 3;
music.play(0);
state++;
statedelay = 75;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
levelcomplete_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3061:
state++;
statedelay = 45;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
crewmate_textbox(175, 174, 175);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3062:
state++;
statedelay = 45;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
remaining_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3063:
state++;
statedelay = 0;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3064:
if (jumppressed)
{
state++;
statedelay = 30;
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 3065:
state = 3070;
statedelay = 0;
break;
case 3070:
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
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
break;
case 3071:
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
if (graphics.fademode == 1) state++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3072:
//Ok, we need to adjust some flags based on who've we've rescued. Some of there conversation options
//change depending on when they get back to the ship.
if (lastsaved == 2)
{
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 (crewstats[3]) obj.flags[25] = true;
if (crewstats[4]) obj.flags[26] = true;
if (crewstats[5]) obj.flags[24] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 3)
{
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 (crewstats[2]) obj.flags[50] = true;
if (crewstats[4]) obj.flags[49] = true;
if (crewstats[5]) obj.flags[48] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 4)
{
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 (crewstats[2]) obj.flags[54] = true;
if (crewstats[3]) obj.flags[55] = true;
if (crewstats[5]) obj.flags[56] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (lastsaved == 5)
{
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 (crewstats[2]) obj.flags[37] = true;
if (crewstats[3]) obj.flags[38] = true;
if (crewstats[4]) obj.flags[39] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
//We're pitch black now, make a decision
companion = 0;
if (crewrescued() == 6)
{
startscript = true;
newscript="startlevel_final";
state = 0;
}
else if (crewrescued() == 4)
{
companion = 11;
supercrewmate = true;
scmprogress = 0;
startscript = true;
newscript = "intermission_1";
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[19] = true;
if (lastsaved == 2) obj.flags[32] = true;
if (lastsaved == 3) obj.flags[35] = true;
if (lastsaved == 4) obj.flags[34] = true;
if (lastsaved == 5) obj.flags[33] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
}
else if (crewrescued() == 5)
{
startscript = true;
newscript = "intermission_2";
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[20] = true;
if (lastsaved == 2) obj.flags[32] = true;
if (lastsaved == 3) obj.flags[35] = true;
if (lastsaved == 4) obj.flags[34] = true;
if (lastsaved == 5) obj.flags[33] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
}
else
{
startscript = true;
newscript="regularreturn";
state = 0;
}
break;
case 3080:
//returning from an intermission, very like 3070
if (inintermission)
{
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
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
companion = 0;
state=3100;
}
else
{
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
unlocknum(7);
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
companion = 0;
state++;
}
break;
case 3081:
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
if (graphics.fademode == 1) state++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3082:
map.finalmode = false;
startscript = true;
newscript="regularreturn";
state = 0;
break;
case 3085:
//returning from an intermission, very like 3070
//return to menu from here
if (inintermission)
{
companion = 0;
supercrewmate = false;
state++;
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
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.fadeout();
state=3100;
}
else
{
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
unlocknum(6);
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
companion = 0;
supercrewmate = false;
state++;
}
break;
case 3086:
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
if (graphics.fademode == 1) state++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3087:
map.finalmode = false;
startscript = true;
newscript="regularreturn";
state = 0;
break;
case 3100:
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
if(graphics.fademode == 1) state++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3101:
Clean up all exit paths to the menu to use common code There are multiple different exit paths to the main menu. In 2.2, they all had a bunch of copy-pasted code. In 2.3 currently, most of them use game.quittomenu(), but there are some stragglers that still use hand-copied code. This is a bit of a problem, because all exit paths should consistently have FILESYSTEM_unmountassets(), as part of the 2.3 feature of per-level custom assets. Furthermore, most (but not all) of the paths call script.hardreset() too, and some of the stragglers don't. So there could be something persisting through to the title screen (like a really long flash/shake timer) that could only persist if exiting to the title screen through those paths. But, actually, it seems like there's a good reason for some of those to not call script.hardreset() - namely, dying or completing No Death Mode and completing a Time Trial presents some information onscreen that would get reset by script.hardreset(), so I'll fix that in a later commit. So what I've done for this commit is found every exit path that didn't already use game.quittomenu(), and made them use game.quittomenu(). As well, some of them had special handling that existed on top of them already having a corresponding entry in game.quittomenu() (but the path would take the special handling because it never did game.quittomenu()), so I removed that special handling as well (e.g. exiting from a custom level used returntomenu(Menu::levellist) when quittomenu() already had that same returntomenu()). The menu that exiting from the level editor returns to is now handled in game.quittomenu() as well, where the map.custommode branch now also checks for map.custommodeforreal. Unfortunately, it seems like entering the level editor doesn't properly initialize map.custommode, so entering the level editor now initializes map.custommode, too. I've also taken the music.play(6) out of game.quittomenu(), because not all exit paths immediately play Presenting VVVVVV, so all exit paths that DO immediately play Presenting VVVVVV now have music.play(6) special-cased for them, which is fine enough for me. Here is the list of all exit paths to the menu: - Exiting through the pause menu (without glitchrunner mode) - Exiting through the pause menu (with glitchrunner mode) - Completing a custom level - Completing a Time Trial - Dying in No Death Mode - Completing No Death Mode - Completing an Intermission replay - Exiting from the level editor - Completing the main game
2021-01-07 23:20:37 +01:00
quittomenu();
music.play(6); //should be after quittomenu();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 3500:
music.fadeout();
state++;
statedelay = 120;
break;
case 3501:
//Game complete!
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
unlockAchievement("vvvvvvgamecomplete");
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
unlocknum(5);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
crewstats[0] = true;
state++;
statedelay = 75;
music.play(7);
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme("", -1, 12, 164, 165, 255);
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
graphics.addline(" ");
graphics.addline("");
graphics.addline("");
graphics.textboxcenterx();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3502:
state++;
statedelay = 45+15;
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme(" All Crew Members Rescued! ", -1, 64, 0, 0, 0);
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
savetime = timestring();
Display centiseconds on time trial result and Game Complete Centiseconds won't be saved to any save file or anything. This is just to make speedrunning a bit more competitive, being able to know the precise time of a time trial or full game run. The time trial par time on the result screen always has ".99" after it. This is basically due to the game comparing the number of seconds to the par number of seconds using less-than-or-equal-to instead of simply less-than.
2020-06-30 00:53:19 +02:00
savetime += "." + help.twodigits(frames*100 / 30);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3503:
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 45;
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
std::string tempstring = help.number(trinkets());
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme("Trinkets Found:", 48, 84, 0,0,0);
graphics.createtextboxflipme(tempstring, 180, 84, 0, 0, 0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 3504:
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 45+15;
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
std::string tempstring = savetime;
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme(" Game Time:", 64, 96, 0,0,0);
graphics.createtextboxflipme(tempstring, 180, 96, 0, 0, 0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 3505:
state++;
statedelay = 45;
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme(" Total Flips:", 64, 123, 0,0,0);
graphics.createtextboxflipme(help.String(totalflips), 180, 123, 0, 0, 0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3506:
state++;
statedelay = 45+15;
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
graphics.createtextboxflipme("Total Deaths:", 64, 135, 0,0,0);
graphics.createtextboxflipme(help.String(deathcounts), 180, 135, 0, 0, 0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3507:
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 45+15;
Switch all flippable text boxes to use createtextboxflipme This ensures that if the player decides to toggle Flip Mode while one of these text boxes is up, they won't be oriented improperly. Additionally, it also de-duplicates a bunch of Flip Mode check code, which is also a win.
2021-03-20 04:07:14 +01:00
std::string tempstring = "Hardest Room (with " + help.String(hardestroomdeaths) + " deaths)";
graphics.createtextboxflipme(tempstring, -1, 158, 0,0,0);
graphics.createtextboxflipme(hardestroom, -1, 170, 0, 0, 0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 3508:
state++;
statedelay = 0;
De-duplicate Level Complete sequence textboxes Every Level Complete sequence is the same copy-pasted thing, but with minor changes. To make my work easier, I'm de-duplicating them so I have less text boxes to change later, and less grind to grind.
2021-03-20 03:37:54 +01:00
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3509:
if (jumppressed)
{
state++;
statedelay = 30;
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
graphics.textboxremove();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 3510:
//Save stats and stuff here
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 (!obj.flags[73])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//flip mode complete
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
unlockAchievement("vvvvvvgamecompleteflip");
Fix still being able to unlock things in custommode This was caused by the fact that not all unlocks were done through the Game::unlocknum() function. Some just set the unlock number directly. But it's fixed now.
2020-07-03 04:56:26 +02:00
unlocknum(19);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't allow setting best game deaths in custom levels Custom levels shouldn't touch main game save data, and best game deaths is no exception. I also added a MAKEANDPLAY ifdef just to be safe.
2021-05-04 04:30:28 +02:00
#ifndef MAKEANDPLAY
if (!map.custommode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't allow setting best game deaths in custom levels Custom levels shouldn't touch main game save data, and best game deaths is no exception. I also added a MAKEANDPLAY ifdef just to be safe.
2021-05-04 04:30:28 +02:00
if (bestgamedeaths == -1)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
bestgamedeaths = deathcounts;
}
Don't allow setting best game deaths in custom levels Custom levels shouldn't touch main game save data, and best game deaths is no exception. I also added a MAKEANDPLAY ifdef just to be safe.
2021-05-04 04:30:28 +02:00
else
{
if (deathcounts < bestgamedeaths)
{
bestgamedeaths = deathcounts;
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't allow setting best game deaths in custom levels Custom levels shouldn't touch main game save data, and best game deaths is no exception. I also added a MAKEANDPLAY ifdef just to be safe.
2021-05-04 04:30:28 +02:00
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
if (bestgamedeaths > -1) {
if (bestgamedeaths <= 500) {
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
unlockAchievement("vvvvvvcomplete500");
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
}
if (bestgamedeaths <= 250) {
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
unlockAchievement("vvvvvvcomplete250");
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
}
if (bestgamedeaths <= 100) {
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
unlockAchievement("vvvvvvcomplete100");
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
}
if (bestgamedeaths <= 50) {
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
unlockAchievement("vvvvvvcomplete50");
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
}
}
Remove trailing whitespace from all files Surprisingly, there's not a lot of it. There is, however, a lot of mixed indentation in this project.
2020-04-02 21:41:33 +02:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
savestatsandsettings();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (nodeathmode)
{
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
unlockAchievement("vvvvvvmaster"); //bloody hell
Fix still being able to unlock things in custommode This was caused by the fact that not all unlocks were done through the Game::unlocknum() function. Some just set the unlock number directly. But it's fixed now.
2020-07-03 04:56:26 +02:00
unlocknum(20);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 3520;
statedelay = 0;
}
else
{
statedelay = 120;
state++;
}
break;
case 3511:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter (long version for level complete)
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].colour = 102;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 30;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 3512:
//Activating a teleporter 2
state++;
statedelay = 15;
flashlight = 5;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3513:
//Activating a teleporter 2
state++;
statedelay = 15;
flashlight = 5;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3514:
//Activating a teleporter 2
state++;
statedelay = 15;
flashlight = 5;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3515:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].colour = 0;
obj.entities[i].invis = true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//we're done here!
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
statedelay = 60;
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 3516:
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
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
break;
case 3517:
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
if (graphics.fademode == 1)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
state++;
statedelay = 30;
}
break;
case 3518:
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
graphics.fademode = 4;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
statedelay = 30;
map.finalmode = false;
map.final_colormode = false;
map.final_mapcol = 0;
map.final_colorframe = 0;
map.finalstretch = false;
Ensure oldcutscenebars is updated when cutscenebarspos is To do this, I've added Graphics::setbars(), to make sure oldcutscenebarspos always gets assigned when cutscenebarspos is. This fixes potential deltaframe rendering issues if these two mismatch.
2021-03-20 07:08:35 +01:00
graphics.setbars(320);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
teleport_to_new_area = true;
teleportscript = "gamecomplete";
break;
case 3520:
//NO DEATH MODE COMPLETE JESUS
hascontrol = false;
crewstats[0] = 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
graphics.fademode = 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
break;
case 3521:
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
if(graphics.fademode == 1) state++;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3522:
Fix No Death Mode results being reset before being shown This does the same thing as the last commit, but for No Death Mode instead of Time Trials. Whenever you die in No Death Mode, or complete it, all the relevant variables get copied to variables prefixed with 'ndmresult' that never get reset by script.hardreset(), and these variables are what titlerender() use, instead of the "live" ones.
2021-01-08 01:18:07 +01:00
copyndmresults();
Clean up all exit paths to the menu to use common code There are multiple different exit paths to the main menu. In 2.2, they all had a bunch of copy-pasted code. In 2.3 currently, most of them use game.quittomenu(), but there are some stragglers that still use hand-copied code. This is a bit of a problem, because all exit paths should consistently have FILESYSTEM_unmountassets(), as part of the 2.3 feature of per-level custom assets. Furthermore, most (but not all) of the paths call script.hardreset() too, and some of the stragglers don't. So there could be something persisting through to the title screen (like a really long flash/shake timer) that could only persist if exiting to the title screen through those paths. But, actually, it seems like there's a good reason for some of those to not call script.hardreset() - namely, dying or completing No Death Mode and completing a Time Trial presents some information onscreen that would get reset by script.hardreset(), so I'll fix that in a later commit. So what I've done for this commit is found every exit path that didn't already use game.quittomenu(), and made them use game.quittomenu(). As well, some of them had special handling that existed on top of them already having a corresponding entry in game.quittomenu() (but the path would take the special handling because it never did game.quittomenu()), so I removed that special handling as well (e.g. exiting from a custom level used returntomenu(Menu::levellist) when quittomenu() already had that same returntomenu()). The menu that exiting from the level editor returns to is now handled in game.quittomenu() as well, where the map.custommode branch now also checks for map.custommodeforreal. Unfortunately, it seems like entering the level editor doesn't properly initialize map.custommode, so entering the level editor now initializes map.custommode, too. I've also taken the music.play(6) out of game.quittomenu(), because not all exit paths immediately play Presenting VVVVVV, so all exit paths that DO immediately play Presenting VVVVVV now have music.play(6) special-cased for them, which is fine enough for me. Here is the list of all exit paths to the menu: - Exiting through the pause menu (without glitchrunner mode) - Exiting through the pause menu (with glitchrunner mode) - Completing a custom level - Completing a Time Trial - Dying in No Death Mode - Completing No Death Mode - Completing an Intermission replay - Exiting from the level editor - Completing the main game
2021-01-07 23:20:37 +01:00
quittomenu();
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
createmenu(Menu::nodeathmodecomplete);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state = 0;
break;
case 4000:
//Activating a teleporter (short version)
state++;
statedelay = 10;
flashlight = 5;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4001:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
//we're done here!
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4002:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 10;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].colour = 0;
obj.entities[i].invis = true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
i = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if(INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[i].tile = 1;
obj.entities[i].colour = 100;
}
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4003:
state = 0;
statedelay = 0;
teleport_to_new_area = true;
break;
case 4010:
//Activating a teleporter (default appear)
state++;
statedelay = 15;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4011:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4012:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 5;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
int j = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = obj.entities[j].xp+44;
obj.entities[i].yp = obj.entities[j].yp+44;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp = obj.entities[i].xp;
obj.entities[i].lerpoldyp = obj.entities[i].yp;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[j].tile = 2;
obj.entities[j].colour = 101;
}
obj.entities[i].colour = 0;
obj.entities[i].invis = false;
obj.entities[i].dir = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].ay = -6;
obj.entities[i].ax = 6;
obj.entities[i].vy = -6;
obj.entities[i].vx = 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4013:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4014:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4015:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4016:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4017:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 3;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4018:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 15;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 1;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4019:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (intimetrial || nodeathmode || inintermission)
{
}
else
{
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
savetele();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getteleporter();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
activetele = true;
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getteleporter() is used unchecked obj.getteleporter() is able to return -1. If there's no check on it, it will end up indexing out-of-bounds, which is Undefined Behavior.
2020-06-13 04:31:08 +02:00
{
teleblock.x = obj.entities[i].xp - 32;
teleblock.y = obj.entities[i].yp - 32;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
teleblock.w = 160;
teleblock.h = 160;
hascontrol = true;
advancetext = false;
state = 0;
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4020:
//Activating a teleporter (default appear)
state++;
statedelay = 15;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4021:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4022:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 5;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
int j = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = obj.entities[j].xp+44;
obj.entities[i].yp = obj.entities[j].yp+44;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp = obj.entities[i].xp;
obj.entities[i].lerpoldyp = obj.entities[i].yp;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[j].tile = 2;
obj.entities[j].colour = 101;
}
obj.entities[i].colour = 0;
obj.entities[i].invis = false;
obj.entities[i].dir = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].ay = -6;
obj.entities[i].ax = 6;
obj.entities[i].vy = -6;
obj.entities[i].vx = 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4023:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 12;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4024:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 12;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4025:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4026:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4027:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 5;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4028:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 15;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 2;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4029:
hascontrol = true;
advancetext = false;
state = 0;
break;
case 4030:
//Activating a teleporter (default appear)
state++;
statedelay = 15;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4031:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4032:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 5;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
int j = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = obj.entities[j].xp+44;
obj.entities[i].yp = obj.entities[j].yp+44;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp = obj.entities[i].xp;
obj.entities[i].lerpoldyp = obj.entities[i].yp;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[j].tile = 2;
obj.entities[j].colour = 101;
}
obj.entities[i].colour = 0;
obj.entities[i].invis = false;
obj.entities[i].dir = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].ay = -6;
obj.entities[i].ax = -6;
obj.entities[i].vy = -6;
obj.entities[i].vx = -6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4033:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 12;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4034:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 12;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4035:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4036:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4037:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 5;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4038:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 15;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 2;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4039:
hascontrol = true;
advancetext = false;
state = 0;
break;
case 4040:
//Activating a teleporter (default appear)
state++;
statedelay = 15;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4041:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4042:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 5;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
int j = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = obj.entities[j].xp+44;
obj.entities[i].yp = obj.entities[j].yp+44;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp = obj.entities[i].xp;
obj.entities[i].lerpoldyp = obj.entities[i].yp;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[j].tile = 2;
obj.entities[j].colour = 101;
}
obj.entities[i].colour = 0;
obj.entities[i].invis = false;
obj.entities[i].dir = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].ay = -6;
obj.entities[i].ax = 6;
obj.entities[i].vy = -6;
obj.entities[i].vx = 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4043:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 12;
obj.entities[i].yp -= 15;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4044:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 12;
obj.entities[i].yp -= 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4045:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 12;
obj.entities[i].yp -= 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4046:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 8;
obj.entities[i].yp -= 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4047:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 6;
obj.entities[i].yp -= 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4048:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 15;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 3;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4049:
hascontrol = true;
advancetext = false;
state = 0;
break;
case 4050:
//Activating a teleporter (default appear)
state++;
statedelay = 15;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4051:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4052:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 5;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
int j = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = obj.entities[j].xp+44;
obj.entities[i].yp = obj.entities[j].yp+44;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp = obj.entities[i].xp;
obj.entities[i].lerpoldyp = obj.entities[i].yp;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[j].tile = 2;
obj.entities[j].colour = 101;
}
obj.entities[i].colour = 0;
obj.entities[i].invis = false;
obj.entities[i].dir = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].ay = -6;
obj.entities[i].ax = 6;
obj.entities[i].vy = -6;
obj.entities[i].vx = 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4053:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 4;
obj.entities[i].yp -= 15;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4054:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 4;
obj.entities[i].yp -= 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4055:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 4;
obj.entities[i].yp -= 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4056:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 4;
obj.entities[i].yp -= 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4057:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 2;
obj.entities[i].yp -= 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4058:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 15;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 1;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4059:
hascontrol = true;
advancetext = false;
state = 0;
break;
case 4060:
//Activating a teleporter (default appear)
state++;
statedelay = 15;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4061:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4062:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 5;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
int j = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = obj.entities[j].xp+44;
obj.entities[i].yp = obj.entities[j].yp+44;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp = obj.entities[i].xp;
obj.entities[i].lerpoldyp = obj.entities[i].yp;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[j].tile = 2;
obj.entities[j].colour = 101;
}
obj.entities[i].colour = 0;
obj.entities[i].invis = false;
obj.entities[i].dir = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].ay = -6;
obj.entities[i].ax = -6;
obj.entities[i].vy = -6;
obj.entities[i].vx = -6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4063:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 28;
obj.entities[i].yp -= 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4064:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 28;
obj.entities[i].yp -= 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4065:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 25;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4066:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 25;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4067:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 20;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4068:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 15;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp -= 16;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4069:
hascontrol = true;
advancetext = false;
state = 0;
break;
case 4070:
//Activating a teleporter (special for final script, player has colour changed to match rescued crewmate)
state++;
statedelay = 15;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4071:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4072:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 5;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
int j = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = obj.entities[j].xp+44;
obj.entities[i].yp = obj.entities[j].yp+44;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp = obj.entities[i].xp;
obj.entities[i].lerpoldyp = obj.entities[i].yp;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[j].tile = 2;
obj.entities[j].colour = 101;
}
obj.entities[i].invis = false;
obj.entities[i].dir = 1;
obj.entities[i].colour = obj.crewcolour(lastsaved);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].ay = -6;
obj.entities[i].ax = 6;
obj.entities[i].vy = -6;
obj.entities[i].vx = 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4073:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4074:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4075:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4076:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4077:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 3;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4078:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 15;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 1;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4079:
state = 0;
startscript = true;
newscript = "finallevel_teleporter";
break;
case 4080:
//Activating a teleporter (default appear)
state++;
statedelay = 15;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4081:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4082:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 5;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
int j = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = obj.entities[j].xp+44;
obj.entities[i].yp = obj.entities[j].yp+44;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp = obj.entities[i].xp;
obj.entities[i].lerpoldyp = obj.entities[i].yp;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[j].tile = 2;
obj.entities[j].colour = 101;
}
obj.entities[i].colour = 0;
obj.entities[i].invis = false;
obj.entities[i].dir = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].ay = -6;
obj.entities[i].ax = 6;
obj.entities[i].vy = -6;
obj.entities[i].vx = 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4083:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4084:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4085:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4086:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4087:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 3;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4088:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 15;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 1;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4089:
startscript = true;
newscript = "gamecomplete_ending";
state = 0;
break;
case 4090:
//Activating a teleporter (default appear)
state++;
statedelay = 15;
flashlight = 5;
screenshake = 90;
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(9);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4091:
//Activating a teleporter 2
state++;
statedelay = 0;
flashlight = 5;
screenshake = 0;
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(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4092:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter 2
state++;
statedelay = 5;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
int j = obj.getteleporter();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = obj.entities[j].xp+44;
obj.entities[i].yp = obj.entities[j].yp+44;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp = obj.entities[i].xp;
obj.entities[i].lerpoldyp = obj.entities[i].yp;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[j].tile = 2;
obj.entities[j].colour = 101;
}
obj.entities[i].colour = 0;
obj.entities[i].invis = false;
obj.entities[i].dir = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].ay = -6;
obj.entities[i].ax = 6;
obj.entities[i].vy = -6;
obj.entities[i].vx = 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4093:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4094:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 10;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4095:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 8;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4096:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4097:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 3;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4098:
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
state++;
statedelay = 15;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp += 1;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of temporary variables in Game::updatestate() With the scope of these variables reduced, it makes analyzing this function easier, as you can now clearly see all temporary variables are actually initialized before they're used.
2020-09-08 09:56:00 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 4099:
if (nocutscenes)
{
startscript = true;
newscript = "levelonecompleteskip";
}
else
{
startscript = true;
newscript = "levelonecomplete_ending";
}
state = 0;
break;
}
}
}
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 Game::gethardestroom(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (currentroomdeaths > hardestroomdeaths)
{
hardestroomdeaths = currentroomdeaths;
hardestroom = map.roomname;
if (map.roomname == "glitch")
{
if (roomx == 42 && roomy == 51)
{
hardestroom = "Rear Vindow";
}
else if (roomx == 48 && roomy == 51)
{
hardestroom = "On the Vaterfront";
}
else if (roomx == 49 && roomy == 51)
{
hardestroom = "The Untouchavles";
}
}
else if (map.roomname == "change")
{
if (roomx == 45 && roomy == 51) hardestroom =map.specialnames[3];
if (roomx == 46 && roomy == 51) hardestroom =map.specialnames[4];
if (roomx == 47 && roomy == 51) hardestroom =map.specialnames[5];
if (roomx == 50 && roomy == 53) hardestroom =map.specialnames[6];
if (roomx == 50 && roomy == 54) hardestroom = map.specialnames[7];
}
Make hardest room "Dimension VVVVVV" if it has no room name The only places where you can die in a room without a room name is the Overworld, and I feel that calling it Dimension VVVVVV is appropriate. You can't naturally die in The Ship nor the Secret Lab, and you can only do it by pressing R, so I didn't feel it appropriate to add checks to make the hardest room be "The Ship" or "The Secret Lab" if you managed to get your hardest room to be a room in either of those areas.
2020-02-04 04:27:49 +01:00
else if (map.roomname == "")
{
hardestroom = "Dimension VVVVVV";
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::deletestats(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Actually delete saves/unlock.vvv in deletestats() Having to blank everything out in the stats file is very kludge-y.
2020-04-26 22:38:24 +02:00
if (!FILESYSTEM_delete("saves/unlock.vvv"))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Actually delete saves/unlock.vvv in deletestats() Having to blank everything out in the stats file is very kludge-y.
2020-04-26 22:38:24 +02:00
puts("Error deleting saves/unlock.vvv");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Actually delete saves/unlock.vvv in deletestats() Having to blank everything out in the stats file is very kludge-y.
2020-04-26 22:38:24 +02:00
else
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Turn unlock/unlocknotify into plain arrays They're always fixed-size, so there's no need to them to be a dynamic vector. I changed their type to `bool` too because they don't need to be `int`s. Also, I replaced the hardcoded 25 constant with at least a name, in case people want to change it in the future.
2020-07-03 01:45:22 +02:00
for (int i = 0; i < numunlock; i++)
Actually delete saves/unlock.vvv in deletestats() Having to blank everything out in the stats file is very kludge-y.
2020-04-26 22:38:24 +02:00
{
unlock[i] = false;
unlocknotify[i] = false;
}
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
for (int i = 0; i < numtrials; i++)
Actually delete saves/unlock.vvv in deletestats() Having to blank everything out in the stats file is very kludge-y.
2020-04-26 22:38:24 +02:00
{
besttimes[i] = -1;
Read and write best time trial frames This is basically just bolting on the "frames" part of a time trial score. There's not enough space to properly show it on the time trial select screen, maybe we can figure something out later. But I at least want to implement the functionality now.
2020-07-01 03:59:16 +02:00
bestframes[i] = -1;
Actually delete saves/unlock.vvv in deletestats() Having to blank everything out in the stats file is very kludge-y.
2020-04-26 22:38:24 +02:00
besttrinkets[i] = -1;
bestlives[i] = -1;
bestrank[i] = -1;
}
Don't unset Flip Mode when deleting all data in M&P Whenever you delete all your save data, your settings aren't changed at all, and you could resave them if you fiddled with a setting somewhere. But the full game doesn't count Flip Mode as a setting, instead it counts it as an unlock. This means deleting your save data would unset Flip Mode in M&P, which would seem weird because in M&P it's just a simple setting. For consistency, Flip Mode shouldn't be unset when deleting save data in M&P.
2020-11-04 06:56:18 +01:00
#ifndef MAKEANDPLAY
Actually delete saves/unlock.vvv in deletestats() Having to blank everything out in the stats file is very kludge-y.
2020-04-26 22:38:24 +02:00
graphics.setflipmode = false;
Don't unset Flip Mode when deleting all data in M&P Whenever you delete all your save data, your settings aren't changed at all, and you could resave them if you fiddled with a setting somewhere. But the full game doesn't count Flip Mode as a setting, instead it counts it as an unlock. This means deleting your save data would unset Flip Mode in M&P, which would seem weird because in M&P it's just a simple setting. For consistency, Flip Mode shouldn't be unset when deleting save data in M&P.
2020-11-04 06:56:18 +01:00
#endif
Actually delete saves/unlock.vvv in deletestats() Having to blank everything out in the stats file is very kludge-y.
2020-04-26 22:38:24 +02:00
stat_trinkets = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::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
{
if (!FILESYSTEM_delete("saves/settings.vvv"))
{
puts("Error deleting saves/settings.vvv");
}
}
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
void Game::unlocknum( int t )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
#if !defined(MAKEANDPLAY)
Don't let custom levels tamper with main game save data Someone being mean could've overwritten the telesaves of unsuspecting players, or unlocked a bunch of stuff which they shouldn't have for those players, using things like the telesave() command and gamestates. To prevent this, return early in Game::savequick(), Game::savetele(), and Game::unlocknum() if we are in custommode.
2020-03-15 16:17:12 +01:00
if (map.custommode)
{
//Don't let custom levels unlock things!
return;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
unlock[t] = true;
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
savestatsandsettings();
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
void Game::loadstats(ScreenSettings* screen_settings)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::loadstats() to TinyXML2 Surprisingly, I only had to change some names and stuff around at the top of the function. The rest of the function could be left untouched and it worked fine.
2020-06-03 19:11:37 +02:00
tinyxml2::XMLDocument doc;
if (!FILESYSTEM_loadTiXml2Document("saves/unlock.vvv", doc))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
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
// Save unlock.vvv only. Maybe we have a settings.vvv laying around too,
// and we don't want to overwrite that!
Fix segfault when settings.vvv or unlock.vvv is missing To fix this bug, all we have to do is just pass the existing ScreenSettings* that we have in loadstats() to savestats(), and in loadsettings() to savesettings(). Fixes #556. Depends on #558.
2020-12-22 01:40:46 +01:00
savestats(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
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
printf("No Stats found. Assuming a new player\n");
}
Convert Game::loadstats() to TinyXML2 Surprisingly, I only had to change some names and stuff around at the top of the function. The rest of the function could be left untouched and it worked fine.
2020-06-03 19:11:37 +02:00
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
tinyxml2::XMLHandle hRoot(NULL);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::loadstats() to TinyXML2 Surprisingly, I only had to change some names and stuff around at the top of the function. The rest of the function could be left untouched and it worked fine.
2020-06-03 19:11:37 +02:00
pElem=hDoc.FirstChildElement().ToElement();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
// should always have a valid root but handle gracefully if it does
if (!pElem)
{
}
;
// save this for later
Convert Game::loadstats() to TinyXML2 Surprisingly, I only had to change some names and stuff around at the top of the function. The rest of the function could be left untouched and it worked fine.
2020-06-03 19:11:37 +02:00
hRoot=tinyxml2::XMLHandle(pElem);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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
tinyxml2::XMLElement* dataNode = hRoot.FirstChildElement("Data").FirstChild().ToElement();
for( pElem = dataNode; pElem; pElem=pElem->NextSiblingElement())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
const char* pKey = pElem->Value();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
const char* pText = pElem->GetText() ;
Add missing pText NULL checks If an XML tag doesn't contain anything inside, pText will be NULL. If that happens without being checked, then NULL will be passed to SDL_strcmp(). SDL_strcmp() will either call libc strcmp() or use its own implementation; both implementations will still dereference the NULL without checking it. This is undefined behavior, so I'm fixing it. The solution is to do what is done with all other XML parsing functions, and to make sure pText gets set to a safe empty string (which is just a pointer to a null terminator) if it happens to be NULL.
2021-03-24 20:19:44 +01:00
if (pText == NULL)
{
pText = "";
}
De-duplicate and use a macro for loading things into plain arrays Since it's basically the same code each time, I might as well just have a macro instead.
2020-07-03 01:58:58 +02:00
LOAD_ARRAY(unlock)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
De-duplicate and use a macro for loading things into plain arrays Since it's basically the same code each time, I might as well just have a macro instead.
2020-07-03 01:58:58 +02:00
LOAD_ARRAY(unlocknotify)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
LOAD_ARRAY(besttimes)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
De-duplicate and use a macro for loading things into plain arrays Since it's basically the same code each time, I might as well just have a macro instead.
2020-07-03 01:58:58 +02:00
LOAD_ARRAY(bestframes)
Read and write best time trial frames This is basically just bolting on the "frames" part of a time trial score. There's not enough space to properly show it on the time trial select screen, maybe we can figure something out later. But I at least want to implement the functionality now.
2020-07-01 03:59:16 +02:00
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
LOAD_ARRAY(besttrinkets)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
LOAD_ARRAY(bestlives)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
LOAD_ARRAY(bestrank)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "bestgamedeaths") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
bestgamedeaths = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "stat_trinkets") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
stat_trinkets = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "swnbestrank") == 0)
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
{
swnbestrank = help.Int(pText);
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "swnrecord") == 0)
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
{
swnrecord = help.Int(pText);
}
}
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
deserializesettings(dataNode, 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
}
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
void Game::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
{
// Don't duplicate controller buttons!
controllerButton_flip.clear();
controllerButton_map.clear();
controllerButton_esc.clear();
controllerButton_restart.clear();
Separate pressing Enter to open map from pressing Enter to interact This is a lot of copy-pasted code, but a little bit of copy-pasting never hurt anyone... The keybind to interact with activity zones and teleporters is now separate from the keybind to open the map, or return to the editor from in-editor playtesting, or restart a time trial. The keybind is now E, and the default controller bind is X. No controller button prompts, but the game didn't have controller button prompts anyways, so whatever. Doing this now because if people's muscle memory are going to be broken by not being able to spam the map keybind anymore, at least we can help a bit by changing the keybind so they can keep spamming it - their muscle memory is going to be broken anyways. This option has to be enabled by going to the speedrunner menu options and selecting "interact button". It is disabled by default. All prompt text needs to be string-interpolated every time they are drawn, because it is possible for people to change which interact button they use in the middle of gameplay, via the in-game options. Closes #736.
2021-04-19 08:23:44 +02:00
controllerButton_interact.clear();
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
for (tinyxml2::XMLElement* pElem = dataNode;
pElem != NULL;
pElem = pElem->NextSiblingElement())
{
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
const char* pKey = pElem->Value();
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
const char* pText = pElem->GetText();
Add missing pText NULL checks If an XML tag doesn't contain anything inside, pText will be NULL. If that happens without being checked, then NULL will be passed to SDL_strcmp(). SDL_strcmp() will either call libc strcmp() or use its own implementation; both implementations will still dereference the NULL without checking it. This is undefined behavior, so I'm fixing it. The solution is to do what is done with all other XML parsing functions, and to make sure pText gets set to a safe empty string (which is just a pointer to a null terminator) if it happens to be NULL.
2021-03-24 20:19:44 +01:00
if (pText == NULL)
{
pText = "";
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "fullscreen") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
screen_settings->fullscreen = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "stretch") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
screen_settings->stretch = help.Int(pText);
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "useLinearFilter") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
screen_settings->linearFilter = help.Int(pText);
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "window_width") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
screen_settings->windowWidth = help.Int(pText);
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "window_height") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
screen_settings->windowHeight = help.Int(pText);
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "noflashingmode") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
noflashingmode = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "colourblindmode") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
colourblindmode = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "setflipmode") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
graphics.setflipmode = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "invincibility") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
map.invincibility = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "slowdown") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
slowdown = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "advanced_smoothing") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
screen_settings->badSignal = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "usingmmmmmm") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove duplicate using-MMMMMM variable from Game game.usingmmmmmm was a duplicate of music.usingmmmmmm, and has been removed.
2020-11-13 01:48:39 +01:00
music.usingmmmmmm = (bool) help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "ghostsenabled") == 0)
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
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
ghostsenabled = help.Int(pText);
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
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "skipfakeload") == 0)
Add an accessibility option to toggle the fake loading screen (#63)
2020-01-13 02:45:44 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
skipfakeload = help.Int(pText);
Add an accessibility option to toggle the fake loading screen (#63)
2020-01-13 02:45:44 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "disablepause") == 0)
Add being able to disable unfocus pause It's sometimes unwanted by people, and it's unwanted enough that there exist instructions to hexedit the binary to remove it ( https://distractionware.com/forum/index.php?topic=3247.0 ). Fun fact, the unfocus pause didn't exist in 2.0.
2020-06-30 04:49:14 +02:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
disablepause = help.Int(pText);
Add being able to disable unfocus pause It's sometimes unwanted by people, and it's unwanted enough that there exist instructions to hexedit the binary to remove it ( https://distractionware.com/forum/index.php?topic=3247.0 ). Fun fact, the unfocus pause didn't exist in 2.0.
2020-06-30 04:49:14 +02:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "over30mode") == 0)
Add being able to toggle over/fixed-30-FPS, off by default There is now an option in "graphic options" named "toggle fps", which toggles whether the game visually runs at 1000/34 FPS or over 1000/34 FPS. It is off by default. I've had to put the entire game loop in yet another set of braces, I'll indent it next commit.
2020-05-04 21:52:57 +02:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
over30mode = help.Int(pText);
Add being able to toggle over/fixed-30-FPS, off by default There is now an option in "graphic options" named "toggle fps", which toggles whether the game visually runs at 1000/34 FPS or over 1000/34 FPS. It is off by default. I've had to put the entire game loop in yet another set of braces, I'll indent it next commit.
2020-05-04 21:52:57 +02:00
}
Add option to re-enable 1-frame input delay This is an option for speedrunners whose muscle memory is precisely trained and used to the 1-frame input delay that existed in 2.2 and below. It is located in Game Options -> Advanced Options, and is off by default. To re-add the 1-frame input delay, we simply move the key.Poll() to the start of the frame, instead of before an input function gets ran - undoing what #535 did. There is a frame ordering-sensitive issue here, where toggling game.inputdelay at the wrong time could cause double-polling. However, we only toggle it in an input function, which regardless is always guaranteed to be ran after key.Poll() (it either happened at the start of the frame or just before the input function got ran), so this is not an issue. But, in case we ever need to toggle this variable in the future, we can just use the defer callbacks system to defer the toggle to the end of the frame - also added by #535. Added at the request of Habeechee on the VVVVVV speedrunning Discord server.
2021-04-02 00:39:56 +02:00
if (SDL_strcmp(pKey, "inputdelay") == 0)
{
inputdelay = help.Int(pText);
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "glitchrunnermode") == 0)
Add glitchrunner mode, in game options Glitchrunner mode is intended to re-enable glitches that existed in older versions of VVVVVV. These glitches were removed because they could legitimately affect a casual player's experience. Glitches like various R-pressing screwery, Space Station 1 skip, telejumping, Gravitron out-of-bounds, etc. will not be patched.
2020-06-25 23:31:37 +02:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
glitchrunnermode = help.Int(pText);
Add glitchrunner mode, in game options Glitchrunner mode is intended to re-enable glitches that existed in older versions of VVVVVV. These glitches were removed because they could legitimately affect a casual player's experience. Glitches like various R-pressing screwery, Space Station 1 skip, telejumping, Gravitron out-of-bounds, etc. will not be patched.
2020-06-25 23:31:37 +02:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "vsync") == 0)
Add VSync graphics option, off by default This is if you want delta-timesteps to go as quickly as possible. Also it seems like on Windows this only has an effect in exclusive fullscreen mode.
2020-05-04 22:19:47 +02:00
{
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
screen_settings->useVsync = help.Int(pText);
Add VSync graphics option, off by default This is if you want delta-timesteps to go as quickly as possible. Also it seems like on Windows this only has an effect in exclusive fullscreen mode.
2020-05-04 22:19:47 +02:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "notextoutline") == 0)
Add text outline as an accessibility option
2020-01-17 18:37:53 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
graphics.notextoutline = help.Int(pText);
Add text outline as an accessibility option
2020-01-17 18:37:53 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "translucentroomname") == 0)
Add an accessibility option to be able to see through the roomname This is the variable dwgfx.translucentroomname and <translucentroomname> in unlock.vvv. This lets you see through the black background of the roomname at the bottom of the screen, i.e. it makes the roomname background translucent. So you can see if someone decides to hide pesky spikes there.
2020-01-25 05:43:04 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
graphics.translucentroomname = help.Int(pText);
Add an accessibility option to be able to see through the roomname This is the variable dwgfx.translucentroomname and <translucentroomname> in unlock.vvv. This lets you see through the black background of the roomname at the bottom of the screen, i.e. it makes the roomname background translucent. So you can see if someone decides to hide pesky spikes there.
2020-01-25 05:43:04 +01:00
}
Add music and sound volume config options This adds <musicvolume> and <soundvolume> tags to unlock.vvv and settings.vvv, so users' volume preferences will be persistent across game sessions. This does not add the user interface to change them from in-game; the next commit will do that.
2021-04-12 02:41:46 +02:00
if (SDL_strcmp(pKey, "musicvolume") == 0)
{
music.user_music_volume = help.Int(pText);
}
if (SDL_strcmp(pKey, "soundvolume") == 0)
{
music.user_sound_volume = help.Int(pText);
}
Separate pressing Enter to open map from pressing Enter to interact This is a lot of copy-pasted code, but a little bit of copy-pasting never hurt anyone... The keybind to interact with activity zones and teleporters is now separate from the keybind to open the map, or return to the editor from in-editor playtesting, or restart a time trial. The keybind is now E, and the default controller bind is X. No controller button prompts, but the game didn't have controller button prompts anyways, so whatever. Doing this now because if people's muscle memory are going to be broken by not being able to spam the map keybind anymore, at least we can help a bit by changing the keybind so they can keep spamming it - their muscle memory is going to be broken anyways. This option has to be enabled by going to the speedrunner menu options and selecting "interact button". It is disabled by default. All prompt text needs to be string-interpolated every time they are drawn, because it is possible for people to change which interact button they use in the middle of gameplay, via the in-game options. Closes #736.
2021-04-19 08:23:44 +02:00
if (SDL_strcmp(pKey, "separate_interact") == 0)
{
separate_interact = help.Int(pText);
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "flipButton") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
SDL_GameControllerButton newButton;
if (GetButtonFromString(pText, &newButton))
{
controllerButton_flip.push_back(newButton);
}
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "enterButton") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
SDL_GameControllerButton newButton;
if (GetButtonFromString(pText, &newButton))
{
controllerButton_map.push_back(newButton);
}
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "escButton") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
SDL_GameControllerButton newButton;
if (GetButtonFromString(pText, &newButton))
{
controllerButton_esc.push_back(newButton);
}
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "restartButton") == 0)
Added ability to bind restart to a controller.
2020-08-09 00:41:59 +02:00
{
SDL_GameControllerButton newButton;
if (GetButtonFromString(pText, &newButton))
{
controllerButton_restart.push_back(newButton);
}
}
Separate pressing Enter to open map from pressing Enter to interact This is a lot of copy-pasted code, but a little bit of copy-pasting never hurt anyone... The keybind to interact with activity zones and teleporters is now separate from the keybind to open the map, or return to the editor from in-editor playtesting, or restart a time trial. The keybind is now E, and the default controller bind is X. No controller button prompts, but the game didn't have controller button prompts anyways, so whatever. Doing this now because if people's muscle memory are going to be broken by not being able to spam the map keybind anymore, at least we can help a bit by changing the keybind so they can keep spamming it - their muscle memory is going to be broken anyways. This option has to be enabled by going to the speedrunner menu options and selecting "interact button". It is disabled by default. All prompt text needs to be string-interpolated every time they are drawn, because it is possible for people to change which interact button they use in the middle of gameplay, via the in-game options. Closes #736.
2021-04-19 08:23:44 +02:00
if (SDL_strcmp(pKey, "interactButton") == 0)
{
SDL_GameControllerButton newButton;
if (GetButtonFromString(pText, &newButton))
{
controllerButton_interact.push_back(newButton);
}
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "controllerSensitivity") == 0)
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
{
Remove duplicate game.controllerSensitivity proxy It wasn't a direct duplicate of key.sensitivity, but it was still basically the same thing. Although to be fair, at least the case-switch conversion didn't get duplicated everywhere unlike game.slowdown. So now key.sensitivity functions the same as game.controllerSensitivity, and it only gets converted to its actual value whenever a joystick input happens in key.Poll(), unlike previously where it got converted every single frame on the title screen (there was even a comment that said "TODO bit wasteful doing this every poll").
2020-11-13 02:16:18 +01:00
key.sensitivity = help.Int(pText);
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if (controllerButton_flip.size() < 1)
{
controllerButton_flip.push_back(SDL_CONTROLLER_BUTTON_A);
}
if (controllerButton_map.size() < 1)
{
controllerButton_map.push_back(SDL_CONTROLLER_BUTTON_Y);
}
if (controllerButton_esc.size() < 1)
{
controllerButton_esc.push_back(SDL_CONTROLLER_BUTTON_B);
}
Added ability to bind restart to a controller.
2020-08-09 00:41:59 +02:00
if (controllerButton_restart.size() < 1)
{
controllerButton_restart.push_back(SDL_CONTROLLER_BUTTON_RIGHTSHOULDER);
}
Separate pressing Enter to open map from pressing Enter to interact This is a lot of copy-pasted code, but a little bit of copy-pasting never hurt anyone... The keybind to interact with activity zones and teleporters is now separate from the keybind to open the map, or return to the editor from in-editor playtesting, or restart a time trial. The keybind is now E, and the default controller bind is X. No controller button prompts, but the game didn't have controller button prompts anyways, so whatever. Doing this now because if people's muscle memory are going to be broken by not being able to spam the map keybind anymore, at least we can help a bit by changing the keybind so they can keep spamming it - their muscle memory is going to be broken anyways. This option has to be enabled by going to the speedrunner menu options and selecting "interact button". It is disabled by default. All prompt text needs to be string-interpolated every time they are drawn, because it is possible for people to change which interact button they use in the middle of gameplay, via the in-game options. Closes #736.
2021-04-19 08:23:44 +02:00
if (controllerButton_interact.size() < 1)
{
controllerButton_interact.push_back(SDL_CONTROLLER_BUTTON_X);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
bool Game::savestats(void)
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
{
Add NULL guards to Game::savestats() and savesettings() This is so those functions can safely be called when graphics.screenbuffer is NULL.
2021-02-16 03:38:42 +01:00
if (graphics.screenbuffer == NULL)
{
return false;
}
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
ScreenSettings screen_settings;
graphics.screenbuffer->GetSettings(&screen_settings);
return savestats(&screen_settings);
}
bool Game::savestats(const ScreenSettings* screen_settings)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::savestats() to TinyXML2 Ok, so it was a bit of a struggle at first figuring out the new API, but honestly it wasn't so bad in the end. I made a copy of my old unlock.vvv before testing this, and checking with `diff` the only difference is the new `encoding="UTF-8"` in the XML declaration, which isn't a bad thing.
2020-06-03 19:59:49 +02:00
tinyxml2::XMLDocument doc;
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
bool already_exists = FILESYSTEM_loadTiXml2Document("saves/unlock.vvv", doc);
if (!already_exists)
{
puts("No unlock.vvv found. Creating new file");
}
xml::update_declaration(doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
tinyxml2::XMLElement * root = xml::update_element(doc, "Save");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_comment(root, " Save file " );
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
tinyxml2::XMLElement * dataNode = xml::update_element(root, "Data");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string s_unlock;
Turn unlock/unlocknotify into plain arrays They're always fixed-size, so there's no need to them to be a dynamic vector. I changed their type to `bool` too because they don't need to be `int`s. Also, I replaced the hardcoded 25 constant with at least a name, in case people want to change it in the future.
2020-07-03 01:45:22 +02:00
for(size_t i = 0; i < SDL_arraysize(unlock); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
s_unlock += help.String(unlock[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "unlock", s_unlock.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string s_unlocknotify;
Turn unlock/unlocknotify into plain arrays They're always fixed-size, so there's no need to them to be a dynamic vector. I changed their type to `bool` too because they don't need to be `int`s. Also, I replaced the hardcoded 25 constant with at least a name, in case people want to change it in the future.
2020-07-03 01:45:22 +02:00
for(size_t i = 0; i < SDL_arraysize(unlocknotify); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
s_unlocknotify += help.String(unlocknotify[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "unlocknotify", s_unlocknotify.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string s_besttimes;
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
for(size_t i = 0; i < SDL_arraysize(besttimes); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
s_besttimes += help.String(besttimes[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "besttimes", s_besttimes.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Read and write best time trial frames This is basically just bolting on the "frames" part of a time trial score. There's not enough space to properly show it on the time trial select screen, maybe we can figure something out later. But I at least want to implement the functionality now.
2020-07-01 03:59:16 +02:00
std::string s_bestframes;
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
for (size_t i = 0; i < SDL_arraysize(bestframes); i++)
Read and write best time trial frames This is basically just bolting on the "frames" part of a time trial score. There's not enough space to properly show it on the time trial select screen, maybe we can figure something out later. But I at least want to implement the functionality now.
2020-07-01 03:59:16 +02:00
{
s_bestframes += help.String(bestframes[i]) + ",";
}
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "bestframes", s_bestframes.c_str());
Read and write best time trial frames This is basically just bolting on the "frames" part of a time trial score. There's not enough space to properly show it on the time trial select screen, maybe we can figure something out later. But I at least want to implement the functionality now.
2020-07-01 03:59:16 +02:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string s_besttrinkets;
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
for(size_t i = 0; i < SDL_arraysize(besttrinkets); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
s_besttrinkets += help.String(besttrinkets[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "besttrinkets", s_besttrinkets.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string s_bestlives;
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
for(size_t i = 0; i < SDL_arraysize(bestlives); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
s_bestlives += help.String(bestlives[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "bestlives", s_bestlives.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string s_bestrank;
Turn time trial stat vectors into plain arrays These are the besttimes, besttrinkets, bestlives, and bestrank attributes of Game. bestframes was already a plain array. As these are always fixed-sized, there's no reason for them to be vectors. Also, I put their size in a static const int so it's easy to change how many of them there are.
2020-07-03 02:09:30 +02:00
for(size_t i = 0; i < SDL_arraysize(bestrank); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
s_bestrank += help.String(bestrank[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "bestrank", s_bestrank.c_str());
xml::update_tag(dataNode, "bestgamedeaths", bestgamedeaths);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "stat_trinkets", stat_trinkets);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
xml::update_tag(dataNode, "swnbestrank", swnbestrank);
xml::update_tag(dataNode, "swnrecord", swnrecord);
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
serializesettings(dataNode, 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
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
return FILESYSTEM_saveTiXml2Document("saves/unlock.vvv", doc);
}
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 Game::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
{
const bool stats_saved = savestats();
const bool settings_saved = savesettings();
Add error messages for failed writes to disk of settings Changing settings would most of the time attempt to save unlock.vvv and now also settings.vvv, but there would be no feedback whether the files have been saved successfully or not. Now, if saving fails when changing settings in the menu, a warning message will be shown. The setting will still be applied of course, but the user will be informed it couldn't be saved. This message can be silenced until the game is restarted, because I can imagine this could get very annoying when someone already knows their settings aren't writeable. Also, some options didn't even save settings in the first place. These are turning off invincibility, and by coincidence precisely all the options in the advanced options menu. I made sure these options now do so.
2020-11-22 03:10:26 +01:00
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
return stats_saved && settings_saved; // Not the same as `savestats() && savesettings()`!
Add error messages for failed writes to disk of settings Changing settings would most of the time attempt to save unlock.vvv and now also settings.vvv, but there would be no feedback whether the files have been saved successfully or not. Now, if saving fails when changing settings in the menu, a warning message will be shown. The setting will still be applied of course, but the user will be informed it couldn't be saved. This message can be silenced until the game is restarted, because I can imagine this could get very annoying when someone already knows their settings aren't writeable. Also, some options didn't even save settings in the first place. These are turning off invincibility, and by coincidence precisely all the options in the advanced options menu. I made sure these options now do so.
2020-11-22 03:10:26 +01:00
}
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 Game::savestatsandsettings_menu(void)
Add error messages for failed writes to disk of settings Changing settings would most of the time attempt to save unlock.vvv and now also settings.vvv, but there would be no feedback whether the files have been saved successfully or not. Now, if saving fails when changing settings in the menu, a warning message will be shown. The setting will still be applied of course, but the user will be informed it couldn't be saved. This message can be silenced until the game is restarted, because I can imagine this could get very annoying when someone already knows their settings aren't writeable. Also, some options didn't even save settings in the first place. These are turning off invincibility, and by coincidence precisely all the options in the advanced options menu. I made sure these options now do so.
2020-11-22 03:10:26 +01:00
{
Refactor Game::savestats() to not use a default argument In order to be able to fix the bug #556, I'm planning on adding ScreenSettings* to the settings.vvv write function. However, that entails adding another argument to Game::savesettings(), which is going to be really messy given the default argument of Game::savestats(). That, combined with the fact that the code comment at the site of the implementation of Game::savestats() being wrong (!!!), leads me to believe that using default function arguments here isn't worth it. Instead, what I've done is made it so callers are explicit about whether or not they're calling savestats(), savesettings(), or both at the same time. If they are calling both at the same time, then they will be using a new function named savestatsandsettings(). In short, these are the interface changes: * bool Game::savestats(bool) has been removed * bool Game::savestatsandsettings() has been added * void Game::savestats_menu() has been renamed to void Game::savestatsandsettings_menu() * All previous callers of bool Game::savestats() are now using bool Game::savestatsandsettings() * The one caller of bool Game::savestats(bool) is now using bool Game::savestats()
2020-12-22 01:03:19 +01:00
// Call Game::savestatsandsettings(), but upon failure, go to the save error screen
if (!savestatsandsettings() && !silence_settings_error)
Add error messages for failed writes to disk of settings Changing settings would most of the time attempt to save unlock.vvv and now also settings.vvv, but there would be no feedback whether the files have been saved successfully or not. Now, if saving fails when changing settings in the menu, a warning message will be shown. The setting will still be applied of course, but the user will be informed it couldn't be saved. This message can be silenced until the game is restarted, because I can imagine this could get very annoying when someone already knows their settings aren't writeable. Also, some options didn't even save settings in the first place. These are turning off invincibility, and by coincidence precisely all the options in the advanced options menu. I made sure these options now do so.
2020-11-22 03:10:26 +01:00
{
createmenu(Menu::errorsavingsettings);
map.nexttowercolour();
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
}
}
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
void Game::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
{
tinyxml2::XMLDocument& doc = xml::get_document(dataNode);
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
xml::update_tag(dataNode, "fullscreen", (int) screen_settings->fullscreen);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
xml::update_tag(dataNode, "stretch", screen_settings->stretch);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
xml::update_tag(dataNode, "useLinearFilter", (int) screen_settings->linearFilter);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
xml::update_tag(dataNode, "window_width", screen_settings->windowWidth);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
xml::update_tag(dataNode, "window_height", screen_settings->windowHeight);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "noflashingmode", noflashingmode);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "colourblindmode", colourblindmode);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "setflipmode", graphics.setflipmode);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "invincibility", map.invincibility);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "slowdown", slowdown);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
xml::update_tag(dataNode, "advanced_smoothing", (int) screen_settings->badSignal);
Remove trailing whitespace from all files Surprisingly, there's not a lot of it. There is, however, a lot of mixed indentation in this project.
2020-04-02 21:41:33 +02:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove duplicate using-MMMMMM variable from Game game.usingmmmmmm was a duplicate of music.usingmmmmmm, and has been removed.
2020-11-13 01:48:39 +01:00
xml::update_tag(dataNode, "usingmmmmmm", music.usingmmmmmm);
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
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "ghostsenabled", (int) ghostsenabled);
Add an accessibility option to toggle the fake loading screen (#63)
2020-01-13 02:45:44 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "skipfakeload", (int) skipfakeload);
Add being able to disable unfocus pause It's sometimes unwanted by people, and it's unwanted enough that there exist instructions to hexedit the binary to remove it ( https://distractionware.com/forum/index.php?topic=3247.0 ). Fun fact, the unfocus pause didn't exist in 2.0.
2020-06-30 04:49:14 +02:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "disablepause", (int) disablepause);
Add text outline as an accessibility option
2020-01-17 18:37:53 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "notextoutline", (int) graphics.notextoutline);
Add an accessibility option to be able to see through the roomname This is the variable dwgfx.translucentroomname and <translucentroomname> in unlock.vvv. This lets you see through the black background of the roomname at the bottom of the screen, i.e. it makes the roomname background translucent. So you can see if someone decides to hide pesky spikes there.
2020-01-25 05:43:04 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "translucentroomname", (int) graphics.translucentroomname);
Add graphics option to toggle mouse cursor Adds an option to show or hide the system mouse cursor over the game window.
2020-01-29 08:17:13 +01:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "over30mode", (int) over30mode);
Add option to re-enable 1-frame input delay This is an option for speedrunners whose muscle memory is precisely trained and used to the 1-frame input delay that existed in 2.2 and below. It is located in Game Options -> Advanced Options, and is off by default. To re-add the 1-frame input delay, we simply move the key.Poll() to the start of the frame, instead of before an input function gets ran - undoing what #535 did. There is a frame ordering-sensitive issue here, where toggling game.inputdelay at the wrong time could cause double-polling. However, we only toggle it in an input function, which regardless is always guaranteed to be ran after key.Poll() (it either happened at the start of the frame or just before the input function got ran), so this is not an issue. But, in case we ever need to toggle this variable in the future, we can just use the defer callbacks system to defer the toggle to the end of the frame - also added by #535. Added at the request of Habeechee on the VVVVVV speedrunning Discord server.
2021-04-02 00:39:56 +02:00
xml::update_tag(dataNode, "inputdelay", (int) inputdelay);
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
xml::update_tag(dataNode, "glitchrunnermode", (int) glitchrunnermode);
Add glitchrunner mode, in game options Glitchrunner mode is intended to re-enable glitches that existed in older versions of VVVVVV. These glitches were removed because they could legitimately affect a casual player's experience. Glitches like various R-pressing screwery, Space Station 1 skip, telejumping, Gravitron out-of-bounds, etc. will not be patched.
2020-06-25 23:31:37 +02:00
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
xml::update_tag(dataNode, "vsync", (int) screen_settings->useVsync);
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
Add music and sound volume config options This adds <musicvolume> and <soundvolume> tags to unlock.vvv and settings.vvv, so users' volume preferences will be persistent across game sessions. This does not add the user interface to change them from in-game; the next commit will do that.
2021-04-12 02:41:46 +02:00
xml::update_tag(dataNode, "musicvolume", music.user_music_volume);
xml::update_tag(dataNode, "soundvolume", music.user_sound_volume);
Separate pressing Enter to open map from pressing Enter to interact This is a lot of copy-pasted code, but a little bit of copy-pasting never hurt anyone... The keybind to interact with activity zones and teleporters is now separate from the keybind to open the map, or return to the editor from in-editor playtesting, or restart a time trial. The keybind is now E, and the default controller bind is X. No controller button prompts, but the game didn't have controller button prompts anyways, so whatever. Doing this now because if people's muscle memory are going to be broken by not being able to spam the map keybind anymore, at least we can help a bit by changing the keybind so they can keep spamming it - their muscle memory is going to be broken anyways. This option has to be enabled by going to the speedrunner menu options and selecting "interact button". It is disabled by default. All prompt text needs to be string-interpolated every time they are drawn, because it is possible for people to change which interact button they use in the middle of gameplay, via the in-game options. Closes #736.
2021-04-19 08:23:44 +02:00
xml::update_tag(dataNode, "separate_interact", (int) separate_interact);
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
// Delete all controller buttons we had previously.
// dataNode->FirstChildElement() shouldn't be NULL at this point...
// we've already added a bunch of elements
for (tinyxml2::XMLElement* element = dataNode->FirstChildElement();
element != NULL;
/* Increment code handled separately */)
{
const char* name = element->Name();
if (SDL_strcmp(name, "flipButton") == 0
|| SDL_strcmp(name, "enterButton") == 0
|| SDL_strcmp(name, "escButton") == 0
Separate pressing Enter to open map from pressing Enter to interact This is a lot of copy-pasted code, but a little bit of copy-pasting never hurt anyone... The keybind to interact with activity zones and teleporters is now separate from the keybind to open the map, or return to the editor from in-editor playtesting, or restart a time trial. The keybind is now E, and the default controller bind is X. No controller button prompts, but the game didn't have controller button prompts anyways, so whatever. Doing this now because if people's muscle memory are going to be broken by not being able to spam the map keybind anymore, at least we can help a bit by changing the keybind so they can keep spamming it - their muscle memory is going to be broken anyways. This option has to be enabled by going to the speedrunner menu options and selecting "interact button". It is disabled by default. All prompt text needs to be string-interpolated every time they are drawn, because it is possible for people to change which interact button they use in the middle of gameplay, via the in-game options. Closes #736.
2021-04-19 08:23:44 +02:00
|| SDL_strcmp(name, "restartButton") == 0
|| SDL_strcmp(name, "interactButton") == 0)
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
{
// Can't just doc.DeleteNode(element) and then go to next,
// element->NextSiblingElement() will be NULL.
// Instead, store pointer of element we want to delete. Then
// increment `element`. And THEN delete the element.
tinyxml2::XMLElement* delete_this = element;
element = element->NextSiblingElement();
doc.DeleteNode(delete_this);
continue;
}
element = element->NextSiblingElement();
}
Add VSync graphics option, off by default This is if you want delta-timesteps to go as quickly as possible. Also it seems like on Windows this only has an effect in exclusive fullscreen mode.
2020-05-04 22:19:47 +02:00
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
// Now add them
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
for (size_t i = 0; i < controllerButton_flip.size(); i += 1)
{
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
tinyxml2::XMLElement* msg = doc.NewElement("flipButton");
Convert Game::savestats() to TinyXML2 Ok, so it was a bit of a struggle at first figuring out the new API, but honestly it wasn't so bad in the end. I made a copy of my old unlock.vvv before testing this, and checking with `diff` the only difference is the new `encoding="UTF-8"` in the XML declaration, which isn't a bad thing.
2020-06-03 19:59:49 +02:00
msg->LinkEndChild(doc.NewText(help.String((int) controllerButton_flip[i]).c_str()));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
dataNode->LinkEndChild(msg);
}
for (size_t i = 0; i < controllerButton_map.size(); i += 1)
{
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
tinyxml2::XMLElement* msg = doc.NewElement("enterButton");
Convert Game::savestats() to TinyXML2 Ok, so it was a bit of a struggle at first figuring out the new API, but honestly it wasn't so bad in the end. I made a copy of my old unlock.vvv before testing this, and checking with `diff` the only difference is the new `encoding="UTF-8"` in the XML declaration, which isn't a bad thing.
2020-06-03 19:59:49 +02:00
msg->LinkEndChild(doc.NewText(help.String((int) controllerButton_map[i]).c_str()));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
dataNode->LinkEndChild(msg);
}
for (size_t i = 0; i < controllerButton_esc.size(); i += 1)
{
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
tinyxml2::XMLElement* msg = doc.NewElement("escButton");
Convert Game::savestats() to TinyXML2 Ok, so it was a bit of a struggle at first figuring out the new API, but honestly it wasn't so bad in the end. I made a copy of my old unlock.vvv before testing this, and checking with `diff` the only difference is the new `encoding="UTF-8"` in the XML declaration, which isn't a bad thing.
2020-06-03 19:59:49 +02:00
msg->LinkEndChild(doc.NewText(help.String((int) controllerButton_esc[i]).c_str()));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
dataNode->LinkEndChild(msg);
}
Added ability to bind restart to a controller.
2020-08-09 00:41:59 +02:00
for (size_t i = 0; i < controllerButton_restart.size(); i += 1)
{
Add XML forwards compatibility to unlock.vvv This file is probably the biggest one, as there will be more settings added in the future and we don't want people's settings to be erased. Of course, this file will be migrated to a settings.vvv sometime later in 2.3 in order to prevent 2.2 from erasing 2.3 settings.
2020-09-25 18:10:10 +02:00
tinyxml2::XMLElement* msg = doc.NewElement("restartButton");
Added ability to bind restart to a controller.
2020-08-09 00:41:59 +02:00
msg->LinkEndChild(doc.NewText(help.String((int) controllerButton_restart[i]).c_str()));
dataNode->LinkEndChild(msg);
}
Separate pressing Enter to open map from pressing Enter to interact This is a lot of copy-pasted code, but a little bit of copy-pasting never hurt anyone... The keybind to interact with activity zones and teleporters is now separate from the keybind to open the map, or return to the editor from in-editor playtesting, or restart a time trial. The keybind is now E, and the default controller bind is X. No controller button prompts, but the game didn't have controller button prompts anyways, so whatever. Doing this now because if people's muscle memory are going to be broken by not being able to spam the map keybind anymore, at least we can help a bit by changing the keybind so they can keep spamming it - their muscle memory is going to be broken anyways. This option has to be enabled by going to the speedrunner menu options and selecting "interact button". It is disabled by default. All prompt text needs to be string-interpolated every time they are drawn, because it is possible for people to change which interact button they use in the middle of gameplay, via the in-game options. Closes #736.
2021-04-19 08:23:44 +02:00
for (size_t i = 0; i < controllerButton_interact.size(); i += 1)
{
tinyxml2::XMLElement* msg = doc.NewElement("interactButton");
msg->LinkEndChild(doc.NewText(help.String((int) controllerButton_interact[i]).c_str()));
dataNode->LinkEndChild(msg);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove duplicate game.controllerSensitivity proxy It wasn't a direct duplicate of key.sensitivity, but it was still basically the same thing. Although to be fair, at least the case-switch conversion didn't get duplicated everywhere unlike game.slowdown. So now key.sensitivity functions the same as game.controllerSensitivity, and it only gets converted to its actual value whenever a joystick input happens in key.Poll(), unlike previously where it got converted every single frame on the title screen (there was even a comment that said "TODO bit wasteful doing this every poll").
2020-11-13 02:16:18 +01:00
xml::update_tag(dataNode, "controllerSensitivity", key.sensitivity);
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
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
void Game::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
{
tinyxml2::XMLDocument doc;
if (!FILESYSTEM_loadTiXml2Document("saves/settings.vvv", doc))
{
Fix segfault when settings.vvv or unlock.vvv is missing To fix this bug, all we have to do is just pass the existing ScreenSettings* that we have in loadstats() to savestats(), and in loadsettings() to savesettings(). Fixes #556. Depends on #558.
2020-12-22 01:40:46 +01:00
savesettings(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
puts("No settings.vvv found");
}
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
tinyxml2::XMLHandle hRoot(NULL);
{
pElem = hDoc.FirstChildElement().ToElement();
// should always have a valid root but handle gracefully if it doesn't
if (!pElem)
{
}
;
// save this for later
hRoot = tinyxml2::XMLHandle(pElem);
}
tinyxml2::XMLElement* dataNode = hRoot.FirstChildElement("Data").FirstChild().ToElement();
Remove duplicate screen configuration variables There were some duplicate Screen configuration variables that were on Game, when there didn't need to be. - game.fullScreenEffect_badSignal is a duplicate of graphics.screenbuffer->badSignalEffect - game.fullscreen is a duplicate of !graphics.screenbuffer->isWindowed - game.stretchMode is a duplicate of graphics.screenbuffer->stretchMode - game.useLinearFilter is a duplicate of graphics.screenbuffer->isFiltered These duplicate variables have been removed now. I put indentation when handling the ScreenSettings struct in main() so the local doesn't live for the entirety of main() (which is the entirety of the program).
2020-11-13 01:45:51 +01:00
deserializesettings(dataNode, 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
}
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 Game::savesettings(void)
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
{
Add NULL guards to Game::savestats() and savesettings() This is so those functions can safely be called when graphics.screenbuffer is NULL.
2021-02-16 03:38:42 +01:00
if (graphics.screenbuffer == NULL)
{
return false;
}
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
ScreenSettings screen_settings;
graphics.screenbuffer->GetSettings(&screen_settings);
return savesettings(&screen_settings);
}
bool Game::savesettings(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
{
tinyxml2::XMLDocument doc;
bool already_exists = FILESYSTEM_loadTiXml2Document("saves/settings.vvv", doc);
if (!already_exists)
{
puts("No settings.vvv found. Creating new file");
}
xml::update_declaration(doc);
tinyxml2::XMLElement* root = xml::update_element(doc, "Settings");
xml::update_comment(root, " Settings (duplicated from unlock.vvv) ");
tinyxml2::XMLElement* dataNode = xml::update_element(root, "Data");
Allow Game::savestats() to accept a pointer to ScreenSettings Another step to fix the bug #556 is to allow Game::savestats() to accept a pointer to an existing ScreenSettings struct. This entails refactoring Game::savesettings() and Game::serializesettings() to accept the function as well, along with adding Screen::GetSettings() so the settings of the current Screen can be easily grabbed.
2020-12-22 01:34:16 +01:00
serializesettings(dataNode, 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
Add error messages for failed writes to disk of settings Changing settings would most of the time attempt to save unlock.vvv and now also settings.vvv, but there would be no feedback whether the files have been saved successfully or not. Now, if saving fails when changing settings in the menu, a warning message will be shown. The setting will still be applied of course, but the user will be informed it couldn't be saved. This message can be silenced until the game is restarted, because I can imagine this could get very annoying when someone already knows their settings aren't writeable. Also, some options didn't even save settings in the first place. These are turning off invincibility, and by coincidence precisely all the options in the advanced options menu. I made sure these options now do so.
2020-11-22 03:10:26 +01:00
return FILESYSTEM_saveTiXml2Document("saves/settings.vvv", doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::customstart(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
jumpheld = true;
savex = edsavex;
savey = edsavey;
saverx = edsaverx;
savery = edsavery;
savegc = edsavegc;
savedir = edsavedir; //Worldmap Start
savepoint = 0;
gravitycontrol = savegc;
state = 0;
deathseq = -1;
lifeseq = 0;
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::start(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
jumpheld = true;
savex = 232;
savey = 113;
saverx = 104;
savery = 110;
savegc = 0;
savedir = 1; //Worldmap Start
savepoint = 0;
gravitycontrol = savegc;
state = 0;
deathseq = -1;
lifeseq = 0;
if (!nocutscenes) music.play(5);
}
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 Game::deathsequence(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
int i;
if (supercrewmate && scmhurt)
{
i = obj.getscm();
}
else
{
i = obj.getplayer();
}
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].colour = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
obj.entities[i].invis = false;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (deathseq == 30)
{
if (nodeathmode)
{
music.fadeout();
gameoverdelay = 60;
}
deathcounts++;
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(2);
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].invis = true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (map.finalmode)
{
Add bounds checks to roomdeaths and roomdeathsfinal This fixes being able to trigger Undefined Behavior by pressing R when not in-bounds in the Outside Dimension VVVVVV map, usually when you're falling upwards towards Game Complete. I also put bounds checks on normal roomdeaths for good measure. You'll never know when you need it.
2020-05-20 02:20:46 +02:00
if (roomx - 41 >= 0 && roomx - 41 < 20 && roomy - 48 >= 0 && roomy - 48 < 20)
{
map.roomdeathsfinal[roomx - 41 + (20 * (roomy - 48))]++;
currentroomdeaths = map.roomdeathsfinal[roomx - 41 + (20 * (roomy - 48))];
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Add bounds checks to roomdeaths and roomdeathsfinal This fixes being able to trigger Undefined Behavior by pressing R when not in-bounds in the Outside Dimension VVVVVV map, usually when you're falling upwards towards Game Complete. I also put bounds checks on normal roomdeaths for good measure. You'll never know when you need it.
2020-05-20 02:20:46 +02:00
if (roomx - 100 >= 0 && roomx - 100 < 20 && roomy - 100 >= 0 && roomy - 100 < 20)
{
map.roomdeaths[roomx - 100 + (20*(roomy - 100))]++;
currentroomdeaths = map.roomdeaths[roomx - 100 + (20 * (roomy - 100))];
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
if (deathseq == 25) obj.entities[i].invis = true;
if (deathseq == 20) obj.entities[i].invis = true;
if (deathseq == 16) obj.entities[i].invis = true;
if (deathseq == 14) obj.entities[i].invis = true;
if (deathseq == 12) obj.entities[i].invis = true;
if (deathseq < 10) obj.entities[i].invis = true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (!nodeathmode)
{
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities) && deathseq <= 1) obj.entities[i].invis = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
gameoverdelay--;
}
}
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
void Game::startspecial( int t )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
jumpheld = true;
switch(t)
{
case 0: //Secret Lab
savex = 104;
savey = 169;
saverx = 118;
savery = 106;
savegc = 0;
savedir = 1;
break;
case 1: //Intermission 1 (any)
savex = 80;
savey = 57;
saverx = 41;
savery = 56;
savegc = 0;
savedir = 0;
break;
default:
savex = 232;
savey = 113;
saverx = 104;
savery = 110;
savegc = 0;
savedir = 1; //Worldmap Start
break;
}
savepoint = 0;
gravitycontrol = savegc;
state = 0;
deathseq = -1;
lifeseq = 0;
}
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
void Game::starttrial( int t )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
jumpheld = true;
switch(t)
{
case 0: //Space Station 1
savex = 200;
savey = 161;
saverx = 113;
savery = 105;
savegc = 0;
savedir = 1;
break;
case 1: //Lab
savex = 191;
savey = 33;
saverx = 102;
savery = 116;
savegc = 0;
savedir = 1;
break;
case 2: //Tower
savex = 84;
savey = 193, saverx = 108;
savery = 109;
savegc = 0;
savedir = 1;
break;
case 3: //Space Station 2
savex = 148;
savey = 38;
saverx = 112;
savery = 114;
savegc = 1;
savedir = 0;
break;
case 4: //Warp
savex = 52;
savey = 73;
saverx = 114;
savery = 101;
savegc = 0;
savedir = 1;
break;
case 5: //Final
savex = 101;
savey = 113;
saverx = 46;
savery = 54;
savegc = 0;
savedir = 1;
break;
default:
savex = 232;
savey = 113;
saverx = 104;
savery = 110;
savegc = 0;
savedir = 1; //Worldmap Start
break;
}
savepoint = 0;
gravitycontrol = savegc;
state = 0;
deathseq = -1;
lifeseq = 0;
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::loadquick(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::loadquick() to TinyXML2 Same changes as all other XML-loading functions.
2020-06-04 02:24:31 +02:00
tinyxml2::XMLDocument doc;
if (!FILESYSTEM_loadTiXml2Document("saves/qsave.vvv", doc)) return;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
readmaingamesave(doc);
}
void Game::readmaingamesave(tinyxml2::XMLDocument& doc)
{
Convert Game::loadquick() to TinyXML2 Same changes as all other XML-loading functions.
2020-06-04 02:24:31 +02:00
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
tinyxml2::XMLHandle hRoot(NULL);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::loadquick() to TinyXML2 Same changes as all other XML-loading functions.
2020-06-04 02:24:31 +02:00
pElem=hDoc.FirstChildElement().ToElement();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
// should always have a valid root but handle gracefully if it does
if (!pElem)
{
printf("Save Not Found\n");
}
// save this for later
Convert Game::loadquick() to TinyXML2 Same changes as all other XML-loading functions.
2020-06-04 02:24:31 +02:00
hRoot=tinyxml2::XMLHandle(pElem);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Convert Game::loadquick() to TinyXML2 Same changes as all other XML-loading functions.
2020-06-04 02:24:31 +02:00
for( pElem = hRoot.FirstChildElement( "Data" ).FirstChild().ToElement(); pElem; pElem=pElem->NextSiblingElement())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
const char* pKey = pElem->Value();;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
const char* pText = pElem->GetText() ;
if(pText == NULL)
{
pText = "";
}
Turn map.explored, map.roomdeaths(final) into plain arrays They're always fixed-size anyways, there's no need for them to be vectors. Also used the new INBOUNDS_ARR() macro for the map.explored bounds checks in Script.cpp, and made map.explored a proper bool array instead of an int array.
2020-07-03 06:01:09 +02:00
LOAD_ARRAY_RENAME(worldmap, map.explored)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn obj.flags into an array instead of a vector Since it's always fixed-size, there's no reason for it to be a vector.
2020-07-03 03:22:19 +02:00
LOAD_ARRAY_RENAME(flags, obj.flags)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
LOAD_ARRAY(crewstats)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn obj.collect and obj.customcollect into plain arrays Since they're always fixed-size, there's no need for them to be vectors. Also added an INBOUNDS_ARR() macro to do bounds checks with plain arrays.
2020-07-03 04:17:32 +02:00
LOAD_ARRAY_RENAME(collect, obj.collect)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "finalmode") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
map.finalmode = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "finalstretch") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
map.finalstretch = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "savex") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savex = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savey") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savey = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "saverx") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
saverx = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savery") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savery = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savegc") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savegc = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savedir") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savedir= help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savepoint") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savepoint = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "companion") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
companion = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "lastsaved") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
lastsaved = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "teleportscript") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
teleportscript = pText;
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "supercrewmate") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
supercrewmate = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "scmprogress") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
scmprogress = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "scmmoveme") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
scmmoveme = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "frames") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
frames = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "seconds") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
seconds = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "minutes") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
minutes = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "hours") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
hours = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "deathcounts") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
deathcounts = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "totalflips") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
totalflips = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "hardestroom") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix <hardestroom> having atoi() called on it when loading quicksave For some reason (probably a copy-paste error), this XML tag gets atoi() called on it before being assigned to Game::hardestroom. And only when loading a quicksave, at that. This would result in Game::hardestroom being set to an empty string, which if you kept until Game Complete, would end up rendering as a single null byte (if you even have a font face for said null byte). I'm not sure how this error compiles in the first place, but whatever.
2020-05-18 23:16:23 +02:00
hardestroom = pText;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "hardestroomdeaths") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
hardestroomdeaths = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "currentsong") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
int song = help.Int(pText);
Fix silent music saves playing MMMMMM track 15 if... This commit fixes a bug that's existed since MMMMMM was added (so, 2.2), where if you quicksaved in a custom level while no music was playing, then quit and loaded that quicksave, and you were using PPPPPP while having MMMMMM available, it would play MMMMMM track 15, even though the game intends for the music to simply be silent. This is due to the same bug that lets you play MMMMMM tracks if you're on PPPPPP - musicclass::play() does a modulo, but C++ modulo is not guaranteed to be positive given negative inputs, so the 16-track offset is added to a negative number, resulting in targeting the MMMMMM soundtrack instead of PPPPPP. That exploit doesn't harm anyone and shouldn't be fixed, EXCEPT it causes a problem in this specific case. But this bug can be fixed without removing that exploit. Note that I made the check do not-equal to -1 instead of greater-than -1, so levels that intend on using track -2, -3, -4, etc. upon loading a quicksave will still work as their creator intended. It's just that specifically -1 is patched out, just to fix this issue.
2020-08-07 03:36:35 +02:00
if (song != -1)
{
music.play(song);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Save showtargets to main game save files This fixes an oversight that could lead to confusion by the player. showtargets is the variable that shows all unexplored teleporters on the map as a question mark, so players know where to head to to make progress. However, it previously was not directly saved to the main game file. Instead, it would be set to true if flag 12 was turned on in the save file. How well does flag 12 correlate with showtargets? Well, the script that turns on showtargets (bigopenworld and bigopenworldskip) doesn't turn it on. Neither does completing Space Station 1. This flag is only turned on when the player activates Violet's activity zone for the first time. Therefore, it's entirely possible that a new player could complete Space Station 1, then save their game, and come back to resume playing later. When they do come back, the question marks that Violet told them about won't show up on the minimap, and they'll be confused. They may not know where to go. And it is completely unintuitive for them to know that in order to get the question marks to show up again, they have to not only talk to Violet, but then save the game again, and reload the save. Especially since the question marks only show up after you reload the save, and not when you talk to Violet (because flag 12 is only a proxy for showtargets, not the actual variable itself). So what's the solution? Just save showtargets to the save file directly.
2021-05-20 22:44:06 +02:00
else if (SDL_strcmp(pKey, "showtargets") == 0)
{
map.showtargets = help.Int(pText);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if (map.finalmode)
{
map.final_colormode = false;
map.final_mapcol = 0;
map.final_colorframe = 0;
}
if (map.finalstretch)
{
map.finalstretch = true;
map.final_colormode = true;
map.final_mapcol = 0;
map.final_colorframe = 1;
}
map.showteleporters = true;
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(obj.flags[12]) map.showtargets = true;
if (obj.flags[42]) map.showtrinkets = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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
void Game::customloadquick(std::string savfile)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
if (cliplaytest) {
savex = playx;
Fix copy-paste bug in command-line playtesting code Found this because when I compiled with Clang, -Wself-assign-field was enabled.
2020-05-04 20:41:38 +02:00
savey = playy;
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
saverx = playrx;
savery = playry;
savegc = playgc;
Fix -playmusic command line option not working There's a bug where playtesting from Ved doesn't properly play the music of the level, due to no fault with Ved. This was because the music was being faded out by scriptclass::startgamemode() case 23 after main() called music.play(). To fix this, just call music.play() when all the other variables are being set in Game::customloadquick().
2020-07-11 20:55:26 +02:00
music.play(playmusic);
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
return;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string levelfile = savfile.substr(7);
Convert Game::customloadquick() to TinyXML2 Ok, who's even reading these commit messages at this point?
2020-06-04 02:34:05 +02:00
tinyxml2::XMLDocument doc;
if (!FILESYSTEM_loadTiXml2Document(("saves/"+levelfile+".vvv").c_str(), doc)) return;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Convert Game::customloadquick() to TinyXML2 Ok, who's even reading these commit messages at this point?
2020-06-04 02:34:05 +02:00
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
tinyxml2::XMLHandle hRoot(NULL);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::customloadquick() to TinyXML2 Ok, who's even reading these commit messages at this point?
2020-06-04 02:34:05 +02:00
pElem=hDoc.FirstChildElement().ToElement();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
// should always have a valid root but handle gracefully if it does
if (!pElem)
{
printf("Save Not Found\n");
}
// save this for later
Convert Game::customloadquick() to TinyXML2 Ok, who's even reading these commit messages at this point?
2020-06-04 02:34:05 +02:00
hRoot=tinyxml2::XMLHandle(pElem);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Convert Game::customloadquick() to TinyXML2 Ok, who's even reading these commit messages at this point?
2020-06-04 02:34:05 +02:00
for( pElem = hRoot.FirstChildElement( "Data" ).FirstChild().ToElement(); pElem; pElem=pElem->NextSiblingElement())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
const char* pKey = pElem->Value();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
const char* pText = pElem->GetText() ;
if(pText == NULL)
{
pText = "";
}
Turn map.explored, map.roomdeaths(final) into plain arrays They're always fixed-size anyways, there's no need for them to be vectors. Also used the new INBOUNDS_ARR() macro for the map.explored bounds checks in Script.cpp, and made map.explored a proper bool array instead of an int array.
2020-07-03 06:01:09 +02:00
LOAD_ARRAY_RENAME(worldmap, map.explored)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn obj.flags into an array instead of a vector Since it's always fixed-size, there's no reason for it to be a vector.
2020-07-03 03:22:19 +02:00
LOAD_ARRAY_RENAME(flags, obj.flags)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
LOAD_ARRAY_RENAME(moods, obj.customcrewmoods)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
LOAD_ARRAY(crewstats)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn obj.collect and obj.customcollect into plain arrays Since they're always fixed-size, there's no need for them to be vectors. Also added an INBOUNDS_ARR() macro to do bounds checks with plain arrays.
2020-07-03 04:17:32 +02:00
LOAD_ARRAY_RENAME(collect, obj.collect)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn obj.collect and obj.customcollect into plain arrays Since they're always fixed-size, there's no need for them to be vectors. Also added an INBOUNDS_ARR() macro to do bounds checks with plain arrays.
2020-07-03 04:17:32 +02:00
LOAD_ARRAY_RENAME(customcollect, obj.customcollect)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "finalmode") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
map.finalmode = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "finalstretch") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
map.finalstretch = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
if (map.finalmode)
{
map.final_colormode = false;
map.final_mapcol = 0;
map.final_colorframe = 0;
}
if (map.finalstretch)
{
map.finalstretch = true;
map.final_colormode = true;
map.final_mapcol = 0;
map.final_colorframe = 1;
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "savex") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savex = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savey") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savey = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "saverx") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
saverx = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savery") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savery = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savegc") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savegc = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savedir") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savedir= help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savepoint") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
savepoint = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "companion") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
companion = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "lastsaved") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
lastsaved = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "teleportscript") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
teleportscript = pText;
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "supercrewmate") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
supercrewmate = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "scmprogress") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
scmprogress = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "scmmoveme") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
scmmoveme = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "frames") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
frames = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "seconds") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
seconds = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "minutes") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
minutes = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "hours") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
hours = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "deathcounts") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
deathcounts = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "totalflips") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
totalflips = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "hardestroom") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix <hardestroom> having atoi() called on it when loading quicksave For some reason (probably a copy-paste error), this XML tag gets atoi() called on it before being assigned to Game::hardestroom. And only when loading a quicksave, at that. This would result in Game::hardestroom being set to an empty string, which if you kept until Game Complete, would end up rendering as a single null byte (if you even have a font face for said null byte). I'm not sure how this error compiles in the first place, but whatever.
2020-05-18 23:16:23 +02:00
hardestroom = pText;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "hardestroomdeaths") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
hardestroomdeaths = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "currentsong") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
int song = help.Int(pText);
Fix silent music saves playing MMMMMM track 15 if... This commit fixes a bug that's existed since MMMMMM was added (so, 2.2), where if you quicksaved in a custom level while no music was playing, then quit and loaded that quicksave, and you were using PPPPPP while having MMMMMM available, it would play MMMMMM track 15, even though the game intends for the music to simply be silent. This is due to the same bug that lets you play MMMMMM tracks if you're on PPPPPP - musicclass::play() does a modulo, but C++ modulo is not guaranteed to be positive given negative inputs, so the 16-track offset is added to a negative number, resulting in targeting the MMMMMM soundtrack instead of PPPPPP. That exploit doesn't harm anyone and shouldn't be fixed, EXCEPT it causes a problem in this specific case. But this bug can be fixed without removing that exploit. Note that I made the check do not-equal to -1 instead of greater-than -1, so levels that intend on using track -2, -3, -4, etc. upon loading a quicksave will still work as their creator intended. It's just that specifically -1 is patched out, just to fix this issue.
2020-08-07 03:36:35 +02:00
if (song != -1)
{
music.play(song);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "showminimap") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
map.customshowmm = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
map.showteleporters = true;
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(obj.flags[12]) map.showtargets = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::loadsummary(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::loadsummary() to TinyXML2
2020-06-04 04:26:54 +02:00
tinyxml2::XMLDocument docTele;
if (!FILESYSTEM_loadTiXml2Document("saves/tsave.vvv", docTele))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
telesummary = "";
}
else
{
Convert Game::loadsummary() to TinyXML2
2020-06-04 04:26:54 +02:00
tinyxml2::XMLHandle hDoc(&docTele);
tinyxml2::XMLElement* pElem;
tinyxml2::XMLHandle hRoot(NULL);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::loadsummary() to TinyXML2
2020-06-04 04:26:54 +02:00
pElem=hDoc.FirstChildElement().ToElement();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
// should always have a valid root but handle gracefully if it does
if (!pElem)
{
printf("Save Not Found\n");
}
// save this for later
Convert Game::loadsummary() to TinyXML2
2020-06-04 04:26:54 +02:00
hRoot=tinyxml2::XMLHandle(pElem);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
int l_minute, l_second, l_hours;
l_minute = l_second= l_hours = 0;
int l_saveX = 0;
int l_saveY = 0;
Convert Game::loadsummary() to TinyXML2
2020-06-04 04:26:54 +02:00
for( pElem = hRoot.FirstChildElement( "Data" ).FirstChild().ToElement(); pElem; pElem=pElem->NextSiblingElement())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
const char* pKey = pElem->Value();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
const char* pText = pElem->GetText() ;
Add missing pText NULL checks If an XML tag doesn't contain anything inside, pText will be NULL. If that happens without being checked, then NULL will be passed to SDL_strcmp(). SDL_strcmp() will either call libc strcmp() or use its own implementation; both implementations will still dereference the NULL without checking it. This is undefined behavior, so I'm fixing it. The solution is to do what is done with all other XML parsing functions, and to make sure pText gets set to a safe empty string (which is just a pointer to a null terminator) if it happens to be NULL.
2021-03-24 20:19:44 +01:00
if (pText == NULL)
{
pText = "";
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "summary") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
telesummary = pText;
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "seconds") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
l_second = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "minutes") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
l_minute = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "hours") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
l_hours = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savery") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
l_saveY = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "saverx") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
l_saveX = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "trinkets") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
tele_trinkets = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "finalmode") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
map.finalmode = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "finalstretch") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
map.finalstretch = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
LOAD_ARRAY_RENAME(crewstats, tele_crewstats)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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
tele_gametime = giventimestring(l_hours,l_minute, l_second);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tele_currentarea = map.currentarea(map.area(l_saveX, l_saveY));
}
Convert Game::loadsummary() to TinyXML2
2020-06-04 04:26:54 +02:00
tinyxml2::XMLDocument doc;
if (!FILESYSTEM_loadTiXml2Document("saves/qsave.vvv", doc))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
quicksummary = "";
}
else
{
Convert Game::loadsummary() to TinyXML2
2020-06-04 04:26:54 +02:00
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
tinyxml2::XMLHandle hRoot(NULL);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::loadsummary() to TinyXML2
2020-06-04 04:26:54 +02:00
pElem=hDoc.FirstChildElement().ToElement();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
// should always have a valid root but handle gracefully if it does
if (!pElem)
{
printf("Save Not Found\n");
}
// save this for later
Convert Game::loadsummary() to TinyXML2
2020-06-04 04:26:54 +02:00
hRoot=tinyxml2::XMLHandle(pElem);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
int l_minute, l_second, l_hours;
l_minute = l_second= l_hours = 0;
int l_saveX = 0;
int l_saveY = 0;
Convert Game::loadsummary() to TinyXML2
2020-06-04 04:26:54 +02:00
for( pElem = hRoot.FirstChildElement( "Data" ).FirstChild().ToElement(); pElem; pElem=pElem->NextSiblingElement())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
const char* pKey = pElem->Value();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
const char* pText = pElem->GetText() ;
Add missing pText NULL checks If an XML tag doesn't contain anything inside, pText will be NULL. If that happens without being checked, then NULL will be passed to SDL_strcmp(). SDL_strcmp() will either call libc strcmp() or use its own implementation; both implementations will still dereference the NULL without checking it. This is undefined behavior, so I'm fixing it. The solution is to do what is done with all other XML parsing functions, and to make sure pText gets set to a safe empty string (which is just a pointer to a null terminator) if it happens to be NULL.
2021-03-24 20:19:44 +01:00
if (pText == NULL)
{
pText = "";
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
if (SDL_strcmp(pKey, "summary") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
quicksummary = pText;
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "seconds") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
l_second = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "minutes") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
l_minute = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "hours") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
l_hours = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "savery") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
l_saveY = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "saverx") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
l_saveX = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "trinkets") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
quick_trinkets = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "finalmode") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
map.finalmode = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't use std::strings when comparing key names There's no need to create an std::string for every single element just to see if it's a key name. At least in libstdc++, there's an optimization where std::strings that are 16 characters or less don't allocate on the heap, and instead use the internal 16-char buffer directly in the control structure of the std::string. However, it's not guaranteed that all the element names we'll get will always be 16 chars or less, and in case the std::string does end up allocating on the heap, we have no reason for it to allocate on the heap; so we should just convert these string comparisons to C strings instead.
2021-03-06 19:31:17 +01:00
else if (SDL_strcmp(pKey, "finalstretch") == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all usages of atoi() with help.Int() This will prevent any undefined behavior that might occur as a result of having invalid input passed into atoi().
2020-08-07 06:31:29 +02:00
map.finalstretch = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
LOAD_ARRAY_RENAME(crewstats, quick_crewstats)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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
quick_gametime = giventimestring(l_hours,l_minute, l_second);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
quick_currentarea = map.currentarea(map.area(l_saveX, l_saveY));
}
}
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 Game::initteleportermode(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Set the teleporter variable to the right position!
teleport_to_teleporter = 0;
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
for (size_t i = 0; i < map.teleporters.size(); i++)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (roomx == map.teleporters[i].x + 100 && roomy == map.teleporters[i].y + 100)
{
teleport_to_teleporter = i;
}
}
}
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 Game::savetele(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Add inspecial() checks to savetele() and savequick() This prevents the game from being saved if you manage to trigger a savetele() during a "special" gamemode (like if you use the Gravitron out-of-bounds glitch when replaying Intermission 2, then go to Game Complete that way).
2020-06-14 05:08:39 +02:00
if (map.custommode || inspecial())
Don't let custom levels tamper with main game save data Someone being mean could've overwritten the telesaves of unsuspecting players, or unlocked a bunch of stuff which they shouldn't have for those players, using things like the telesave() command and gamestates. To prevent this, return early in Game::savequick(), Game::savetele(), and Game::unlocknum() if we are in custommode.
2020-03-15 16:17:12 +01:00
{
//Don't trash save data!
Add error message if telesave fails At least, whenever it would say "Game Saved", it now instead gives an error message if saving is not successful.
2020-11-04 02:58:38 +01:00
return false;
Don't let custom levels tamper with main game save data Someone being mean could've overwritten the telesaves of unsuspecting players, or unlocked a bunch of stuff which they shouldn't have for those players, using things like the telesave() command and gamestates. To prevent this, return early in Game::savequick(), Game::savetele(), and Game::unlocknum() if we are in custommode.
2020-03-15 16:17:12 +01:00
}
Convert Game::savetele() to TinyXML2 I just had to find-and-replace all `new TiXmlDocument` to `doc.NewDocument` and `new TiXmlText` to `doc.NewText`, along some other stuff.
2020-06-03 20:39:33 +02:00
tinyxml2::XMLDocument doc;
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
bool already_exists = FILESYSTEM_loadTiXml2Document("saves/tsave.vvv", doc);
if (!already_exists)
{
puts("No tsave.vvv found. Creating new file");
}
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
telesummary = writemaingamesave(doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add error message if telesave fails At least, whenever it would say "Game Saved", it now instead gives an error message if saving is not successful.
2020-11-04 02:58:38 +01:00
if(!FILESYSTEM_saveTiXml2Document("saves/tsave.vvv", doc))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
printf("Could Not Save game!\n");
Make saveFilePath not an std::string Since it only ever gets assigned from FILESYSTEM_getUserSaveDirectory(), and that function returns a C string, and the variable is only ever read from again, this doesn't need to be an std::string.
2021-03-07 00:30:22 +01:00
printf("Failed: %s%s\n", saveFilePath, "tsave.vvv");
Add error message if telesave fails At least, whenever it would say "Game Saved", it now instead gives an error message if saving is not successful.
2020-11-04 02:58:38 +01:00
return false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add error message if telesave fails At least, whenever it would say "Game Saved", it now instead gives an error message if saving is not successful.
2020-11-04 02:58:38 +01:00
printf("Game saved\n");
return true;
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
bool Game::savequick(void)
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
{
if (map.custommode || inspecial())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
//Don't trash save data!
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
return false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
tinyxml2::XMLDocument doc;
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
bool already_exists = FILESYSTEM_loadTiXml2Document("saves/qsave.vvv", doc);
if (!already_exists)
{
puts("No qsave.vvv found. Creating new file");
}
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
quicksummary = writemaingamesave(doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
if(!FILESYSTEM_saveTiXml2Document("saves/qsave.vvv", doc))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
printf("Could Not Save game!\n");
Make saveFilePath not an std::string Since it only ever gets assigned from FILESYSTEM_getUserSaveDirectory(), and that function returns a C string, and the variable is only ever read from again, this doesn't need to be an std::string.
2021-03-07 00:30:22 +01:00
printf("Failed: %s%s\n", saveFilePath, "qsave.vvv");
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
return false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
printf("Game saved\n");
return true;
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
// Returns summary of save
std::string Game::writemaingamesave(tinyxml2::XMLDocument& doc)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
//TODO make this code a bit cleaner.
Add inspecial() checks to savetele() and savequick() This prevents the game from being saved if you manage to trigger a savetele() during a "special" gamemode (like if you use the Gravitron out-of-bounds glitch when replaying Intermission 2, then go to Game Complete that way).
2020-06-14 05:08:39 +02:00
if (map.custommode || inspecial())
Don't let custom levels tamper with main game save data Someone being mean could've overwritten the telesaves of unsuspecting players, or unlocked a bunch of stuff which they shouldn't have for those players, using things like the telesave() command and gamestates. To prevent this, return early in Game::savequick(), Game::savetele(), and Game::unlocknum() if we are in custommode.
2020-03-15 16:17:12 +01:00
{
//Don't trash save data!
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
return "";
Don't let custom levels tamper with main game save data Someone being mean could've overwritten the telesaves of unsuspecting players, or unlocked a bunch of stuff which they shouldn't have for those players, using things like the telesave() command and gamestates. To prevent this, return early in Game::savequick(), Game::savetele(), and Game::unlocknum() if we are in custommode.
2020-03-15 16:17:12 +01:00
}
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_declaration(doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
tinyxml2::XMLElement * root = xml::update_element(doc, "Save");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_comment(root, " Save file " );
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
tinyxml2::XMLElement * msgs = xml::update_element(root, "Data");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Flags, map and stats
std::string mapExplored;
Turn map.explored, map.roomdeaths(final) into plain arrays They're always fixed-size anyways, there's no need for them to be vectors. Also used the new INBOUNDS_ARR() macro for the map.explored bounds checks in Script.cpp, and made map.explored a proper bool array instead of an int array.
2020-07-03 06:01:09 +02:00
for(size_t i = 0; i < SDL_arraysize(map.explored); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
mapExplored += help.String(map.explored[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "worldmap", mapExplored.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string flags;
Turn obj.flags into an array instead of a vector Since it's always fixed-size, there's no reason for it to be a vector.
2020-07-03 03:22:19 +02:00
for(size_t i = 0; i < SDL_arraysize(obj.flags); i++ )
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
flags += help.String((int) obj.flags[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "flags", flags.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string crewstatsString;
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
for(size_t i = 0; i < SDL_arraysize(crewstats); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
crewstatsString += help.String(crewstats[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "crewstats", crewstatsString.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string collect;
Turn obj.collect and obj.customcollect into plain arrays Since they're always fixed-size, there's no need for them to be vectors. Also added an INBOUNDS_ARR() macro to do bounds checks with plain arrays.
2020-07-03 04:17:32 +02:00
for(size_t i = 0; i < SDL_arraysize(obj.collect); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change obj.collect into a vector of bools It's already treated like a bunch of bools anyway, so might as well just formalize it.
2020-04-09 08:56:36 +02:00
collect += help.String((int) obj.collect[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "collect", collect.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Position
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "savex", savex);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "savey", savey);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "saverx", saverx);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "savery", savery);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "savegc", savegc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "savedir", savedir);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "savepoint", savepoint);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "trinkets", trinkets());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Special stats
Remove outdated comments from Game.cpp Most of this is telecookie/quickcookie stuff, which was used in the Flash version, but there's no longer any such thing as a save cookie. Also one TODO that says to make a function that's now been made.
2020-04-03 00:11:45 +02:00
Change nicefade to bool instead of int If it's treated like a bool, why shouldn't it be one?
2020-11-06 09:20:58 +01:00
if (music.nicefade)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "currentsong", music.nicechange);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "currentsong", music.currentsong);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Save showtargets to main game save files This fixes an oversight that could lead to confusion by the player. showtargets is the variable that shows all unexplored teleporters on the map as a question mark, so players know where to head to to make progress. However, it previously was not directly saved to the main game file. Instead, it would be set to true if flag 12 was turned on in the save file. How well does flag 12 correlate with showtargets? Well, the script that turns on showtargets (bigopenworld and bigopenworldskip) doesn't turn it on. Neither does completing Space Station 1. This flag is only turned on when the player activates Violet's activity zone for the first time. Therefore, it's entirely possible that a new player could complete Space Station 1, then save their game, and come back to resume playing later. When they do come back, the question marks that Violet told them about won't show up on the minimap, and they'll be confused. They may not know where to go. And it is completely unintuitive for them to know that in order to get the question marks to show up again, they have to not only talk to Violet, but then save the game again, and reload the save. Especially since the question marks only show up after you reload the save, and not when you talk to Violet (because flag 12 is only a proxy for showtargets, not the actual variable itself). So what's the solution? Just save showtargets to the save file directly.
2021-05-20 22:44:06 +02:00
xml::update_tag(msgs, "showtargets", (int) map.showtargets);
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "teleportscript", teleportscript.c_str());
xml::update_tag(msgs, "companion", companion);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "lastsaved", lastsaved);
Axe BoolToString() in favor of int casts When I encountered this function, I asked myself, why make a dedicated function instead of casting to int? Well, as it turns out, you can't just cast to int, because you have to convert it to a string by doing help.String(number).c_str(), like all the other ints. So it's actually more wasteful to do it the normal way instead of using BoolToString(). That is, until my recent changes came along and made it so that you can just provide an int and it'll automatically be converted to a string, no questions asked. Now, it's more optimal to do a straight cast to int instead of having to go through a middleman function. So this function is getting axed in favor of casting to int instead.
2020-09-25 18:11:52 +02:00
xml::update_tag(msgs, "supercrewmate", (int) supercrewmate);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "scmprogress", scmprogress);
Axe BoolToString() in favor of int casts When I encountered this function, I asked myself, why make a dedicated function instead of casting to int? Well, as it turns out, you can't just cast to int, because you have to convert it to a string by doing help.String(number).c_str(), like all the other ints. So it's actually more wasteful to do it the normal way instead of using BoolToString(). That is, until my recent changes came along and made it so that you can just provide an int and it'll automatically be converted to a string, no questions asked. Now, it's more optimal to do a straight cast to int instead of having to go through a middleman function. So this function is getting axed in favor of casting to int instead.
2020-09-25 18:11:52 +02:00
xml::update_tag(msgs, "scmmoveme", (int) scmmoveme);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "frames", frames);
xml::update_tag(msgs, "seconds", seconds);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "minutes", minutes);
xml::update_tag(msgs, "hours", hours);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "deathcounts", deathcounts);
xml::update_tag(msgs, "totalflips", totalflips);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "hardestroom", hardestroom.c_str());
xml::update_tag(msgs, "hardestroomdeaths", hardestroomdeaths);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Axe BoolToString() in favor of int casts When I encountered this function, I asked myself, why make a dedicated function instead of casting to int? Well, as it turns out, you can't just cast to int, because you have to convert it to a string by doing help.String(number).c_str(), like all the other ints. So it's actually more wasteful to do it the normal way instead of using BoolToString(). That is, until my recent changes came along and made it so that you can just provide an int and it'll automatically be converted to a string, no questions asked. Now, it's more optimal to do a straight cast to int instead of having to go through a middleman function. So this function is getting axed in favor of casting to int instead.
2020-09-25 18:11:52 +02:00
xml::update_tag(msgs, "finalmode", (int) map.finalmode);
xml::update_tag(msgs, "finalstretch", (int) map.finalstretch);
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
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
std::string summary = savearea + ", " + timestring();
Add XML forwards compatibility to tsave.vvv and qsave.vvv These files are probably not of much consequence. The main game isn't going to have things to be added to it anytime soon.
2020-09-25 18:10:48 +02:00
xml::update_tag(msgs, "summary", summary.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
return summary;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
bool Game::customsavequick(std::string savfile)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
const std::string levelfile = savfile.substr(7);
Convert Game::customsavequick() to TinyXML2 At this point I stopped actually doing a quick test, and just went off of "if it compiles, it works".
2020-06-04 02:36:27 +02:00
tinyxml2::XMLDocument doc;
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
bool already_exists = FILESYSTEM_loadTiXml2Document(("saves/" + levelfile + ".vvv").c_str(), doc);
if (!already_exists)
{
printf("No %s.vvv found. Creating new file\n", levelfile.c_str());
}
xml::update_declaration(doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
tinyxml2::XMLElement * root = xml::update_element(doc, "Save");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_comment(root, " Save file ");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
tinyxml2::XMLElement * msgs = xml::update_element(root, "Data");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Flags, map and stats
std::string mapExplored;
Turn map.explored, map.roomdeaths(final) into plain arrays They're always fixed-size anyways, there's no need for them to be vectors. Also used the new INBOUNDS_ARR() macro for the map.explored bounds checks in Script.cpp, and made map.explored a proper bool array instead of an int array.
2020-07-03 06:01:09 +02:00
for(size_t i = 0; i < SDL_arraysize(map.explored); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
mapExplored += help.String(map.explored[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "worldmap", mapExplored.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string flags;
Turn obj.flags into an array instead of a vector Since it's always fixed-size, there's no reason for it to be a vector.
2020-07-03 03:22:19 +02:00
for(size_t i = 0; i < SDL_arraysize(obj.flags); i++ )
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
flags += help.String((int) obj.flags[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "flags", flags.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string moods;
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
for(size_t i = 0; i < SDL_arraysize(obj.customcrewmoods); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
moods += help.String(obj.customcrewmoods[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "moods", moods.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string crewstatsString;
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
for(size_t i = 0; i < SDL_arraysize(crewstats); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change all UtilityClass::something to help.something This changes something like UtilityClass::String to help.String, basically. It takes less typing this way, and is a neat effect of having global args actually be global variables.
2020-04-02 21:30:37 +02:00
crewstatsString += help.String(crewstats[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "crewstats", crewstatsString.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string collect;
Turn obj.collect and obj.customcollect into plain arrays Since they're always fixed-size, there's no need for them to be vectors. Also added an INBOUNDS_ARR() macro to do bounds checks with plain arrays.
2020-07-03 04:17:32 +02:00
for(size_t i = 0; i < SDL_arraysize(obj.collect); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change obj.collect into a vector of bools It's already treated like a bunch of bools anyway, so might as well just formalize it.
2020-04-09 08:56:36 +02:00
collect += help.String((int) obj.collect[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "collect", collect.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::string customcollect;
Turn obj.collect and obj.customcollect into plain arrays Since they're always fixed-size, there's no need for them to be vectors. Also added an INBOUNDS_ARR() macro to do bounds checks with plain arrays.
2020-07-03 04:17:32 +02:00
for(size_t i = 0; i < SDL_arraysize(obj.customcollect); i++ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Make obj.customcollect a vector of bools It's already treated as a vector of bools, so might as well formally declare it as that.
2020-04-09 08:58:03 +02:00
customcollect += help.String((int) obj.customcollect[i]) + ",";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "customcollect", customcollect.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Position
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "savex", savex);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "savey", savey);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "saverx", saverx);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "savery", savery);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "savegc", savegc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "savedir", savedir);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "savepoint", savepoint);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "trinkets", trinkets());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "crewmates", crewmates());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Special stats
Remove outdated comments from Game.cpp Most of this is telecookie/quickcookie stuff, which was used in the Flash version, but there's no longer any such thing as a save cookie. Also one TODO that says to make a function that's now been made.
2020-04-03 00:11:45 +02:00
Change nicefade to bool instead of int If it's treated like a bool, why shouldn't it be one?
2020-11-06 09:20:58 +01:00
if (music.nicefade)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "currentsong", music.nicechange );
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "currentsong", music.currentsong);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "teleportscript", teleportscript.c_str());
xml::update_tag(msgs, "companion", companion);
xml::update_tag(msgs, "lastsaved", lastsaved);
Axe BoolToString() in favor of int casts When I encountered this function, I asked myself, why make a dedicated function instead of casting to int? Well, as it turns out, you can't just cast to int, because you have to convert it to a string by doing help.String(number).c_str(), like all the other ints. So it's actually more wasteful to do it the normal way instead of using BoolToString(). That is, until my recent changes came along and made it so that you can just provide an int and it'll automatically be converted to a string, no questions asked. Now, it's more optimal to do a straight cast to int instead of having to go through a middleman function. So this function is getting axed in favor of casting to int instead.
2020-09-25 18:11:52 +02:00
xml::update_tag(msgs, "supercrewmate", (int) supercrewmate);
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "scmprogress", scmprogress);
Axe BoolToString() in favor of int casts When I encountered this function, I asked myself, why make a dedicated function instead of casting to int? Well, as it turns out, you can't just cast to int, because you have to convert it to a string by doing help.String(number).c_str(), like all the other ints. So it's actually more wasteful to do it the normal way instead of using BoolToString(). That is, until my recent changes came along and made it so that you can just provide an int and it'll automatically be converted to a string, no questions asked. Now, it's more optimal to do a straight cast to int instead of having to go through a middleman function. So this function is getting axed in favor of casting to int instead.
2020-09-25 18:11:52 +02:00
xml::update_tag(msgs, "scmmoveme", (int) scmmoveme);
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "frames", frames);
xml::update_tag(msgs, "seconds", seconds);
xml::update_tag(msgs, "minutes", minutes);
xml::update_tag(msgs, "hours", hours);
xml::update_tag(msgs, "deathcounts", deathcounts);
xml::update_tag(msgs, "totalflips", totalflips);
xml::update_tag(msgs, "hardestroom", hardestroom.c_str());
xml::update_tag(msgs, "hardestroomdeaths", hardestroomdeaths);
Axe BoolToString() in favor of int casts When I encountered this function, I asked myself, why make a dedicated function instead of casting to int? Well, as it turns out, you can't just cast to int, because you have to convert it to a string by doing help.String(number).c_str(), like all the other ints. So it's actually more wasteful to do it the normal way instead of using BoolToString(). That is, until my recent changes came along and made it so that you can just provide an int and it'll automatically be converted to a string, no questions asked. Now, it's more optimal to do a straight cast to int instead of having to go through a middleman function. So this function is getting axed in favor of casting to int instead.
2020-09-25 18:11:52 +02:00
xml::update_tag(msgs, "showminimap", (int) map.customshowmm);
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
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
std::string summary = savearea + ", " + timestring();
Add XML forwards compatibility to custom level quicksaves Now these files might have things added to them in the future? I'm not so sure. But at least they're XML forwards-compatible now.
2020-09-25 18:11:03 +02:00
xml::update_tag(msgs, "summary", summary.c_str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
customquicksummary = summary;
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
if(!FILESYSTEM_saveTiXml2Document(("saves/"+levelfile+".vvv").c_str(), doc))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
printf("Could Not Save game!\n");
Make saveFilePath not an std::string Since it only ever gets assigned from FILESYSTEM_getUserSaveDirectory(), and that function returns a C string, and the variable is only ever read from again, this doesn't need to be an std::string.
2021-03-07 00:30:22 +01:00
printf("Failed: %s%s%s\n", saveFilePath, levelfile.c_str(), ".vvv");
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
return false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
printf("Game saved\n");
return true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Fix a few missing implicit void arg declarations While working on #535, I noticed that editormenuactionpress() still didn't do the explicit void declaration. Then I ran `rg 'void.*\(\)'` and found three other functions that I somehow missed in #628. Whoops. Well, now they no longer are missed.
2021-03-19 05:20:05 +01:00
void Game::loadtele(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Convert Game::loadtele() to TinyXML2 Again, the only thing that needs to be changed is just the code at the top of the function.
2020-06-03 20:04:36 +02:00
tinyxml2::XMLDocument doc;
if (!FILESYSTEM_loadTiXml2Document("saves/tsave.vvv", doc)) return;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
De-duplicate reading/writing main game telesave/quicksave The game has four different functions for the same XML schema: Game::loadtele(), Game::savetele(), Game::loadquick(), and Game::savequick(). This essentially means one XML schema has been copy-pasted three different times. I can at least trim that number down to being copy-pasted only one time by de-duplicating the reading and writing part. So both Game::loadtele() and Game::loadquick() now use Game::readmaingamesave(), and Game::savetele() and Game::savequick() now use Game::writemaingamesave(). This will make it take less work to add XML forwards compatibility (#373).
2020-09-14 01:31:02 +02:00
readmaingamesave(doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
std::string Game::unrescued(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Randomly return the name of an unrescued crewmate
if (fRandom() * 100 > 50)
{
if (!crewstats[5]) return "Victoria";
if (!crewstats[2]) return "Vitellary";
if (!crewstats[4]) return "Verdigris";
if (!crewstats[3]) return "Vermilion";
}
else
{
if (fRandom() * 100 > 50)
{
if (!crewstats[2]) return "Vitellary";
if (!crewstats[4]) return "Verdigris";
if (!crewstats[3]) return "Vermilion";
if (!crewstats[5]) return "Victoria";
}
else
{
if (!crewstats[4]) return "Verdigris";
if (!crewstats[3]) return "Vermilion";
if (!crewstats[5]) return "Victoria";
if (!crewstats[2]) return "Vitellary";
}
}
return "you";
}
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 Game::gameclock(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Don't tick timer if in time trial countdown In 2.2 and previous, the game would call resetgameclock() every frame for the last 30 frames of the time trial countdown in order to make sure it gets reset. This was in a render function, and didn't get brought out in 2.3, so 2.3 resets the game clock *while rendering*, which is kinda bad and is an oversight on my part for not noticing. Instead of doing that, just add a conditional to the timer so that it won't tick during the time trial countdown. This fixes #699 even further by making it so the time trial par can't even be lost during the countdown, because the timer won't tick up - so you can never get a sad squeak to play by pausing the game or unfocus-pausing it during the countdown.
2021-04-13 23:38:45 +02:00
if (timetrialcountdown > 0)
{
return;
}
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
frames++;
if (frames >= 30)
{
frames -= 30;
seconds++;
if (seconds >= 60)
{
seconds -= 60;
minutes++;
if (minutes >= 60)
{
minutes -= 60;
hours++;
}
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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
std::string Game::giventimestring( int hrs, int min, int sec )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
std::string tempstring = "";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (hrs > 0)
{
tempstring += help.String(hrs) + ":";
}
tempstring += help.twodigits(min) + ":" + help.twodigits(sec);
return tempstring;
}
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 Game::timestring(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
std::string tempstring = "";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (hours > 0)
{
tempstring += help.String(hours) + ":";
}
tempstring += help.twodigits(minutes) + ":" + help.twodigits(seconds);
return tempstring;
}
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 Game::partimestring(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//given par time in seconds:
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
std::string tempstring = "";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (timetrialpar >= 60)
{
tempstring = help.twodigits(int((timetrialpar - (timetrialpar % 60)) / 60)) + ":" + help.twodigits(timetrialpar % 60);
}
else
{
tempstring = "00:" + help.twodigits(timetrialpar);
}
return tempstring;
}
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 Game::resulttimestring(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//given result time in seconds:
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
std::string tempstring = "";
Fix time trial result displaying 00:60 instead of 01:00 If your time was exactly 60 seconds, it would display 00:60 instead of 01:00.
2020-06-15 02:51:39 +02:00
if (timetrialresulttime >= 60)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
tempstring = help.twodigits(int((timetrialresulttime - (timetrialresulttime % 60)) / 60)) + ":"
+ help.twodigits(timetrialresulttime % 60);
}
else
{
tempstring = "00:" + help.twodigits(timetrialresulttime);
}
Display centiseconds on time trial result and Game Complete Centiseconds won't be saved to any save file or anything. This is just to make speedrunning a bit more competitive, being able to know the precise time of a time trial or full game run. The time trial par time on the result screen always has ".99" after it. This is basically due to the game comparing the number of seconds to the par number of seconds using less-than-or-equal-to instead of simply less-than.
2020-06-30 00:53:19 +02:00
tempstring += "." + help.twodigits(timetrialresultframes*100 / 30);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
return tempstring;
}
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
std::string Game::timetstring( int t )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//given par time in seconds:
Move tempstring off of Graphics, Game, and UtilityClass Unlike, say, the scriptclass i/j/k stuff, these tempstrings are only purely visual, and there's no known glitches to manipulate them anyway. Thus I think it's safe to make this cleanup.
2020-04-03 00:05:41 +02:00
std::string tempstring = "";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (t >= 60)
{
tempstring = help.twodigits(int((t - (t % 60)) / 60)) + ":" + help.twodigits(t % 60);
}
else
{
tempstring = "00:" + help.twodigits(t);
}
return tempstring;
}
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 Game::returnmenu(void)
Add function Game::returnmenu() It simply goes to the previous menu stack frame.
2020-04-17 04:16:40 +02:00
{
if (menustack.empty())
{
puts("Error: returning to previous menu frame on empty stack!");
return;
}
MenuStackFrame& frame = menustack[menustack.size()-1];
//Store this in case createmenu() removes the stack frame
int previousoption = frame.option;
createmenu(frame.name, true);
currentmenuoption = previousoption;
//Remove the stackframe now, but createmenu() might have already gotten to it
//if we were returning to the main menu
if (!menustack.empty())
{
menustack.pop_back();
}
}
Add function Game::returntomenu() When exiting from a game-gamestate which may have been entered through a varying amount of menus, the solution is to not use Game::returnmenu(), and to instead have a way to go back to a certain given menu.
2020-04-26 02:36:36 +02:00
void Game::returntomenu(enum Menu::MenuName t)
{
if (currentmenuname == t)
{
Re-create menu if returntomenu() is given current menu This fixes a bug where if you had the play menu in a state where the first option was "new game", then kept playing up until a quicksave or telesave was created, then quit to the menu, the menu wouldn't update. Thanks to KSSBrawl for reporting this bug to me: https://cdn.discordapp.com/attachments/708567577978470410/712060797924147240/untitled.webm
2020-05-19 00:19:56 +02:00
createmenu(t, true);
Add function Game::returntomenu() When exiting from a game-gamestate which may have been entered through a varying amount of menus, the solution is to not use Game::returnmenu(), and to instead have a way to go back to a certain given menu.
2020-04-26 02:36:36 +02:00
return;
}
//Unwind the menu stack until we reach our desired menu
int i = menustack.size() - 1;
while (i >= 0)
{
//If we pop it off we can't reference it anymore, so check for it now
bool is_the_menu_we_want = menustack[i].name == t;
returnmenu();
if (is_the_menu_we_want)
{
break;
}
i--;
}
}
Push a stack frame when Game::createmenu() is called Unless it's the main menu, or unless it's not the same menu. Whether or not the menu is the same is left up to the caller, because some menus could be the same but use different names, so we can't simply automatically check that the names are different and assume that they aren't the same menu.
2020-04-17 04:04:36 +02:00
void Game::createmenu( enum Menu::MenuName t, bool samemenu/*= false*/ )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Push a stack frame when Game::createmenu() is called Unless it's the main menu, or unless it's not the same menu. Whether or not the menu is the same is left up to the caller, because some menus could be the same but use different names, so we can't simply automatically check that the names are different and assume that they aren't the same menu.
2020-04-17 04:04:36 +02:00
if (t == Menu::mainmenu)
{
//Either we've just booted up the game or returned from gamemode
//Whichever it is, we shouldn't have a stack,
//and most likely don't have a current stackframe
menustack.clear();
}
else if (!samemenu)
{
MenuStackFrame frame;
frame.option = currentmenuoption;
frame.name = currentmenuname;
menustack.push_back(frame);
Keep currentmenuoption if it's the same menu When recreating the same menu, there's basically no reason to reset the currently-selected menu option. (Also, no need to worry about indexing out of bounds or anything - the number gets checked while iterating over all menu options; it's never used to actually index anything. At worst there might be a 1-frame flicker as the bounds code in gameinput() kicks in, but that shouldn't happen anyways.)
2021-03-05 09:42:55 +01:00
currentmenuoption = 0;
Push a stack frame when Game::createmenu() is called Unless it's the main menu, or unless it's not the same menu. Whether or not the menu is the same is left up to the caller, because some menus could be the same but use different names, so we can't simply automatically check that the names are different and assume that they aren't the same menu.
2020-04-17 04:04:36 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
currentmenuname = t;
menuyoff = 0;
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 maxspacing = 30; // maximum value for menuspacing, can only become lower.
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menucountdown = 0;
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
menuoptions.clear();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
switch (t)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::mainmenu:
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
#if !defined(MAKEANDPLAY)
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
option("play");
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
#endif
#if !defined(NO_CUSTOM_LEVELS)
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
option("levels");
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
#endif
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
option("options");
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
#if !defined(MAKEANDPLAY)
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
option("credits");
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
#endif
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
option("quit");
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
menuyoff = -10;
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
maxspacing = 15;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Add option to allow custom levels when the editor is disabled
2020-02-10 03:21:19 +01:00
#if !defined(NO_CUSTOM_LEVELS)
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::playerworlds:
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
option("play a level");
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
#if !defined(NO_EDITOR)
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
option("level editor");
#endif
Add "open level folder" option to playerworlds menu This simply adds another menu option utilizing what I added in the previous commit.
2020-04-18 03:50:10 +02:00
option("open level folder", FILESYSTEM_openDirectoryEnabled());
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
option("back to menu");
Add option to allow custom levels when the editor is disabled
2020-02-10 03:21:19 +01:00
menuyoff = -40;
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
maxspacing = 15;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::levellist:
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if(ed.ListOfMetaData.size()==0)
{
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
option("ok");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = -20;
}
else
{
for(int i=0; i<(int) ed.ListOfMetaData.size(); i++) // FIXME: int/size_t! -flibit
{
if(i>=levelpage*8 && i< (levelpage*8)+8)
{
//This is, er, suboptimal. Whatever, life optimisation and all that
int tvar=-1;
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
for(size_t j=0; j<customlevelstats.size(); j++)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
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
if(ed.ListOfMetaData[i].filename.substr(7) == customlevelstats[j].name)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
tvar=j;
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
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Remove usage of std::string from MenuOption Instead, the string in MenuOption is just a buffer of 161 chars, which is 40 chars (160 bytes if each were the largest possible UTF-8 character size) plus a null terminator. This is because the maximum length of a menu option that can be fit on the screen without going past is 40 chars.
2020-07-04 06:30:31 +02:00
const char* prefix;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if(tvar>=0)
{
Remove usage of std::string from MenuOption Instead, the string in MenuOption is just a buffer of 161 chars, which is 40 chars (160 bytes if each were the largest possible UTF-8 character size) plus a null terminator. This is because the maximum length of a menu option that can be fit on the screen without going past is 40 chars.
2020-07-04 06:30:31 +02:00
switch (customlevelstats[tvar].score)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove usage of std::string from MenuOption Instead, the string in MenuOption is just a buffer of 161 chars, which is 40 chars (160 bytes if each were the largest possible UTF-8 character size) plus a null terminator. This is because the maximum length of a menu option that can be fit on the screen without going past is 40 chars.
2020-07-04 06:30:31 +02:00
case 0:
{
static const char tmp[] = " ";
prefix = tmp;
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Remove usage of std::string from MenuOption Instead, the string in MenuOption is just a buffer of 161 chars, which is 40 chars (160 bytes if each were the largest possible UTF-8 character size) plus a null terminator. This is because the maximum length of a menu option that can be fit on the screen without going past is 40 chars.
2020-07-04 06:30:31 +02:00
case 1:
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove usage of std::string from MenuOption Instead, the string in MenuOption is just a buffer of 161 chars, which is 40 chars (160 bytes if each were the largest possible UTF-8 character size) plus a null terminator. This is because the maximum length of a menu option that can be fit on the screen without going past is 40 chars.
2020-07-04 06:30:31 +02:00
static const char tmp[] = " * ";
prefix = tmp;
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Remove usage of std::string from MenuOption Instead, the string in MenuOption is just a buffer of 161 chars, which is 40 chars (160 bytes if each were the largest possible UTF-8 character size) plus a null terminator. This is because the maximum length of a menu option that can be fit on the screen without going past is 40 chars.
2020-07-04 06:30:31 +02:00
case 3:
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove usage of std::string from MenuOption Instead, the string in MenuOption is just a buffer of 161 chars, which is 40 chars (160 bytes if each were the largest possible UTF-8 character size) plus a null terminator. This is because the maximum length of a menu option that can be fit on the screen without going past is 40 chars.
2020-07-04 06:30:31 +02:00
static const char tmp[] = "** ";
prefix = tmp;
break;
}
Warning fix for uninitialized prefix
2020-07-15 18:11:23 +02:00
default:
SDL_assert(0 && "Unhandled menu text prefix!");
prefix = "";
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else
{
Remove usage of std::string from MenuOption Instead, the string in MenuOption is just a buffer of 161 chars, which is 40 chars (160 bytes if each were the largest possible UTF-8 character size) plus a null terminator. This is because the maximum length of a menu option that can be fit on the screen without going past is 40 chars.
2020-07-04 06:30:31 +02:00
static const char tmp[] = " ";
prefix = tmp;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
De-duplicate number of menu text bytes I've moved this to a define that gets declared in Game.h. I could've made it a const int, but that's only legal in C++ mode.
2021-03-07 03:14:44 +01:00
char text[MENU_TEXT_BYTES];
Remove usage of std::string from MenuOption Instead, the string in MenuOption is just a buffer of 161 chars, which is 40 chars (160 bytes if each were the largest possible UTF-8 character size) plus a null terminator. This is because the maximum length of a menu option that can be fit on the screen without going past is 40 chars.
2020-07-04 06:30:31 +02:00
SDL_snprintf(text, sizeof(text), "%s%s", prefix, ed.ListOfMetaData[i].title.c_str());
Fix reading uninitialized memory when creating Menu::levellist Valgrind reported this. The error here is that the buffer here is only guaranteed to be initialized up until (and including) the null-terminator, by SDL_snprintf(). Iterating over the entire allocated buffer is bad and I should feel bad as the girl who wrote this code; doing that reads uninitialized memory and passes it to SDL_tolower(). As a bonus, the iterator increment is now a preincrement instead of a postincrement.
2021-02-16 04:18:46 +01:00
for (size_t ii = 0; text[ii] != '\0'; ++ii)
Remove use of std::transform(), use SDL_toupper/lower There's no need to use a template here. Just manually call SDL_tolower() or SDL_toupper() as needed. Oh yeah, and use SDL_tolower() and SDL_toupper() instead of libc tolower() and toupper().
2020-07-03 23:54:23 +02:00
{
text[ii] = SDL_tolower(text[ii]);
}
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
option(text);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
if((size_t) ((levelpage*8)+8) <ed.ListOfMetaData.size())
{
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
option("next page");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
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
option("first page");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add a "previous page" option to the levels list This makes it more convenient if you have a large levels directory, as some people in the VVVVVV custom levels community do. On the first page, this option will change to be "last page" instead. Since the addition of another menu option pushes up the list of levels too close to the selected level data itself, I've had to move the list of levels down by 4 pixels (but "next page"/"previous page"/"return to menu" are still in their same position). This feature was already added to VCE but hasn't been upstreamed until now.
2020-04-17 08:05:49 +02:00
if (levelpage == 0)
{
option("last page");
}
else
{
option("previous page");
}
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
option("return to menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
menuxoff = 20;
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
menuyoff = 70-(menuoptions.size()*10);
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
menuspacing = 5;
return; // skip automatic centering, will turn out bad with levels list
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
#endif
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::quickloadlevel:
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
option("continue from save");
option("start from beginning");
option("back to levels");
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
menuyoff = -30;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::youwannaquit:
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
option("yes, quit");
option("no, return");
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
menuyoff = -20;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::errornostart:
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
option("ok");
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
menuyoff = -20;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
case Menu::gameplayoptions:
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
#if !defined(MAKEANDPLAY)
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
if (ingame_titlemode && unlock[18])
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
#endif
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
{
option("flip mode");
}
option("toggle fps");
option("speedrun options");
option("advanced options");
option("clear data");
option("return");
menuyoff = -10;
maxspacing = 15;
break;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::graphicoptions:
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
option("toggle fullscreen");
Change "toggle letterbox" to "scaling mode" This change was half-backported from the localization branch, except I just came up with "scaling mode" as a better term than the more generic "graphics mode". It doesn't make sense to still have the option be called "toggle letterbox" because a third option (integer mode) was added at some point.
2020-06-30 22:36:57 +02:00
option("scaling mode");
Move "resize to nearest" grouped with other resolution-related options The options for fullscreen and scaling mode were at the top, then there were various other graphical options, and then the option to resize to the nearest window size that is of an integer multiple was all the way below that. Now that last option is moved to be right below the other options related to window sizing.
2020-06-30 22:30:59 +02:00
option("resize to nearest", graphics.screenbuffer->isWindowed);
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
option("toggle filter");
option("toggle analogue");
Add VSync graphics option, off by default This is if you want delta-timesteps to go as quickly as possible. Also it seems like on Windows this only has an effect in exclusive fullscreen mode.
2020-05-04 22:19:47 +02:00
option("toggle vsync");
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
option("return");
Add "resize to nearest" graphics option If you want your game window to simply be exactly 320x240, or 640x480, or 960x720 etc. then it's really annoying that there's no easy way to do this (to clarify, this is different from integer mode, which controls the size of the game INSIDE the window). The easiest way would be having to close the game, go into unlock.vvv, and edit the window size manually. VCE has a 1x/2x/3x/4x graphics option to solve this, although it does not account for actual monitor size (those 1x/2x/3x/4x modes are all you get, whether or not you have a monitor too small for some of them or too big for any of them to be what you want). I discussed this with flibit, and he said that VCE's approach (if it accounted for monitor size) wouldn't work on high-retina displays or high DPIs, because getting the actual multiplier to account for those monitors is kind of a pain. So the next best thing would be to add an option that resizes to the nearest perfect multiple of 320x240. That way you could simply resize the window and let the game correct any imperfect dimensions automatically.
2020-06-30 07:02:21 +02:00
menuyoff = -10;
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
maxspacing = 15;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::ed_settings:
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
option("change description");
option("edit scripts");
option("change music");
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
option("editor ghosts");
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
option("load level");
option("save level");
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
option("options");
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
option("quit to main menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = -20;
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
maxspacing = 15;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::ed_desc:
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
option("change name");
option("change author");
option("change description");
option("change website");
option("back to settings");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 6;
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
maxspacing = 15;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::ed_music:
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
option("next song");
Add previous song option to editor music screen This is just a small quality-of-life feature - it's annoying to have to press ACTION 15 times in order to cycle back through to the previous song.
2021-03-05 09:55:57 +01:00
option("previous song");
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
option("back");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 16;
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
maxspacing = 15;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::ed_quit:
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
option("yes, save and quit");
option("no, quit without saving");
option("return to editor");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 8;
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
maxspacing = 15;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::options:
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
option("gameplay");
option("graphics");
Add audio category to options menu The audio category contains the MMMMMM soundtrack option, as well as stubs for the soon-to-be-implemented volume slider options.
2021-04-12 00:18:35 +02:00
option("audio");
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
option("game pad");
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
option("accessibility");
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
option("return");
menuyoff = 0;
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
maxspacing = 15;
break;
case Menu::speedrunneroptions:
option("glitchrunner mode");
option("input delay");
Separate pressing Enter to open map from pressing Enter to interact This is a lot of copy-pasted code, but a little bit of copy-pasting never hurt anyone... The keybind to interact with activity zones and teleporters is now separate from the keybind to open the map, or return to the editor from in-editor playtesting, or restart a time trial. The keybind is now E, and the default controller bind is X. No controller button prompts, but the game didn't have controller button prompts anyways, so whatever. Doing this now because if people's muscle memory are going to be broken by not being able to spam the map keybind anymore, at least we can help a bit by changing the keybind so they can keep spamming it - their muscle memory is going to be broken anyways. This option has to be enabled by going to the speedrunner menu options and selecting "interact button". It is disabled by default. All prompt text needs to be string-interpolated every time they are drawn, because it is possible for people to change which interact button they use in the middle of gameplay, via the in-game options. Closes #736.
2021-04-19 08:23:44 +02:00
option("interact button");
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
option("fake load screen");
option("return");
menuyoff = 0;
maxspacing = 15;
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
break;
case Menu::advancedoptions:
option("unfocus pause");
option("room name background");
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
option("return");
Add audio category to options menu The audio category contains the MMMMMM soundtrack option, as well as stubs for the soon-to-be-implemented volume slider options.
2021-04-12 00:18:35 +02:00
menuyoff = 0;
maxspacing = 15;
break;
case Menu::audiooptions:
option("music volume");
option("sound volume");
if (music.mmmmmm)
{
option("soundtrack");
}
option("return");
Fix mixed indentation in Game.cpp and Game.h This removes all indentation that suddenly switches in the middle of a function. Most particularly egregious offenses are the ones made by the person who has 2-wide tabs, but keeps tabbing up to make each indentation level match up with the 4-wide spaces, so to them (and only them) it will look just fine, but since by default tabstop is 8-wide, their lines are pushed off all the way to the right.
2020-04-02 22:01:55 +02:00
menuyoff = 0;
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
maxspacing = 15;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::accessibility:
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
#if !defined(MAKEANDPLAY)
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
option("unlock play modes");
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
#endif
Factor out Secret Lab/Time Trial/NDM conds to function They are now factored out to an inline function named incompetitive(). This is so their usage can be changed without having to change each individual one in every place. This also clarifies the intent of using these conditionals (they are for when we're in a "competitive" mode).
2021-05-04 03:22:59 +02:00
option("invincibility", !ingame_titlemode || !incompetitive());
option("slowdown", !ingame_titlemode || !incompetitive());
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
option("animated backgrounds");
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
option("screen effects");
option("text outline");
option("return");
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
menuyoff = 0;
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
maxspacing = 15;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::controller:
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
option("analog stick sensitivity");
option("bind flip");
option("bind enter");
option("bind menu");
Missed adding the option to the createmenu method.
2020-08-09 01:06:20 +02:00
option("bind restart");
Separate pressing Enter to open map from pressing Enter to interact This is a lot of copy-pasted code, but a little bit of copy-pasting never hurt anyone... The keybind to interact with activity zones and teleporters is now separate from the keybind to open the map, or return to the editor from in-editor playtesting, or restart a time trial. The keybind is now E, and the default controller bind is X. No controller button prompts, but the game didn't have controller button prompts anyways, so whatever. Doing this now because if people's muscle memory are going to be broken by not being able to spam the map keybind anymore, at least we can help a bit by changing the keybind so they can keep spamming it - their muscle memory is going to be broken anyways. This option has to be enabled by going to the speedrunner menu options and selecting "interact button". It is disabled by default. All prompt text needs to be string-interpolated every time they are drawn, because it is possible for people to change which interact button they use in the middle of gameplay, via the in-game options. Closes #736.
2021-04-19 08:23:44 +02:00
option("bind interact");
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
option("return");
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
menuyoff = 0;
Fix whitespace from eee98b0e071507a80e9ceec55eb29ca87a102319 eee98b0e071507a80e9ceec55eb29ca87a102319 introduced mixed indentation and one trailing whitespace, which I've cleaned up.
2021-04-09 17:53:55 +02:00
maxspacing = 10;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::cleardatamenu:
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
option("no! don't delete");
option("yes, delete everything");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 64;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::setinvincibility:
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
option("no, return to options");
option("yes, enable");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 64;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Rename Menu::setslowdown2 to Menu::setslowdown Now that setslowdown1 has been removed it's no longer necessary to have a 2 on the end of setslowdown2.
2020-04-17 01:02:01 +02:00
case Menu::setslowdown:
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
option("normal speed");
option("80% speed");
option("60% speed");
option("40% speed");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 16;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::unlockmenu:
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
option("unlock time trials");
option("unlock intermissions", !unlock[16]);
option("unlock no death mode", !unlock[17]);
option("unlock flip mode", !unlock[18]);
option("unlock ship jukebox", (stat_trinkets<20));
option("unlock secret lab", !unlock[8]);
option("return");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = -20;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits:
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
option("next page");
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
option("last page");
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
option("return");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 64;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits2:
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
option("next page");
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
option("previous page");
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
option("return");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 64;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits25:
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
option("next page");
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
option("previous page");
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
option("return");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 64;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits3:
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
option("next page");
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
option("previous page");
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
option("return");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 64;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits4:
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
option("next page");
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
option("previous page");
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
option("return");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 64;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits5:
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
option("next page");
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
option("previous page");
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
option("return");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 64;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::credits6:
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
option("first page");
Add a "previous page" option to the credits menu The credits aren't super-long, but it's still nice to have this menu option. If it's the first page, "previous page" will be "last page" instead.
2020-04-17 08:37:49 +02:00
option("previous page");
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
option("return");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 64;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::play:
Move temp int off of Game This temp variable isn't used anywhere else, and even if it was it's set to something every time it's used, so there's no risk of this commit breaking any backwards compatibility.
2020-04-17 01:08:56 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Ok, here's where the unlock stuff comes into it:
//First up, time trials:
Move temp int off of Game This temp variable isn't used anywhere else, and even if it was it's set to something every time it's used, so there's no risk of this commit breaking any backwards compatibility.
2020-04-17 01:08:56 +02:00
int temp = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (unlock[0] && stat_trinkets >= 3 && !unlocknotify[9]) temp++;
if (unlock[1] && stat_trinkets >= 6 && !unlocknotify[10]) temp++;
if (unlock[2] && stat_trinkets >= 9 && !unlocknotify[11]) temp++;
if (unlock[3] && stat_trinkets >= 12 && !unlocknotify[12]) temp++;
if (unlock[4] && stat_trinkets >= 15 && !unlocknotify[13]) temp++;
if (unlock[5] && stat_trinkets >= 18 && !unlocknotify[14]) temp++;
if (temp > 0)
{
//you've unlocked a time trial!
if (unlock[0] && stat_trinkets >= 3)
{
unlocknotify[9] = true;
unlock[9] = true;
}
if (unlock[1] && stat_trinkets >= 6)
{
unlocknotify[10] = true;
unlock[10] = true;
}
if (unlock[2] && stat_trinkets >= 9)
{
unlocknotify[11] = true;
unlock[11] = true;
}
if (unlock[3] && stat_trinkets >= 12)
{
unlocknotify[12] = true;
unlock[12] = true;
}
if (unlock[4] && stat_trinkets >= 15)
{
unlocknotify[13] = true;
unlock[13] = true;
}
if (unlock[5] && stat_trinkets >= 18)
{
unlocknotify[14] = true;
unlock[14] = true;
}
if (temp == 1)
{
Fix dupe stack frame when creating unlock notif menu The samemenu argument to createmenu() just has to be set to true so another stack frame doesn't get added. Fixes #415.
2020-08-03 06:37:52 +02:00
createmenu(Menu::unlocktimetrial, true);
Remove game.savemystats This variable seems to have been intended to make sure game.savestatsandsettings() was called at the end of the frame, or make sure that it didn't get called more than once per frame. I don't see any frame ordering-related reason why it needs to be called specifically at the end of the frame (the function doesn't modify any state), so it's more plausible that it was added to make sure it didn't get called more than one per frame. However, upon further analysis, none of the code paths where game.savemystats is used ever calls or sets game.savemystats more than once, and a majority of the code directly calls game.savestatsandsettings() anyway, so there's no reason for this variable to exist. If we ever need to make sure it doesn't get called more than once, and there's no way to change the code paths around to prevent it otherwise, we can use the defer callbacks system that I added to #535, when it gets merged.
2021-01-11 04:39:19 +01:00
savestatsandsettings();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (temp > 1)
{
Fix dupe stack frame when creating unlock notif menu The samemenu argument to createmenu() just has to be set to true so another stack frame doesn't get added. Fixes #415.
2020-08-03 06:37:52 +02:00
createmenu(Menu::unlocktimetrials, true);
Remove game.savemystats This variable seems to have been intended to make sure game.savestatsandsettings() was called at the end of the frame, or make sure that it didn't get called more than once per frame. I don't see any frame ordering-related reason why it needs to be called specifically at the end of the frame (the function doesn't modify any state), so it's more plausible that it was added to make sure it didn't get called more than one per frame. However, upon further analysis, none of the code paths where game.savemystats is used ever calls or sets game.savemystats more than once, and a majority of the code directly calls game.savestatsandsettings() anyway, so there's no reason for this variable to exist. If we ever need to make sure it doesn't get called more than once, and there's no way to change the code paths around to prevent it otherwise, we can use the defer callbacks system that I added to #535, when it gets merged.
2021-01-11 04:39:19 +01:00
savestatsandsettings();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else
{
//Alright, we haven't unlocked any time trials. How about no death mode?
temp = 0;
if (bestrank[0] >= 2) temp++;
if (bestrank[1] >= 2) temp++;
if (bestrank[2] >= 2) temp++;
if (bestrank[3] >= 2) temp++;
if (bestrank[4] >= 2) temp++;
if (bestrank[5] >= 2) temp++;
if (temp >= 4 && !unlocknotify[17])
{
//Unlock No Death Mode
unlocknotify[17] = true;
unlock[17] = true;
Fix dupe stack frame when creating unlock notif menu The samemenu argument to createmenu() just has to be set to true so another stack frame doesn't get added. Fixes #415.
2020-08-03 06:37:52 +02:00
createmenu(Menu::unlocknodeathmode, true);
Remove game.savemystats This variable seems to have been intended to make sure game.savestatsandsettings() was called at the end of the frame, or make sure that it didn't get called more than once per frame. I don't see any frame ordering-related reason why it needs to be called specifically at the end of the frame (the function doesn't modify any state), so it's more plausible that it was added to make sure it didn't get called more than one per frame. However, upon further analysis, none of the code paths where game.savemystats is used ever calls or sets game.savemystats more than once, and a majority of the code directly calls game.savestatsandsettings() anyway, so there's no reason for this variable to exist. If we ever need to make sure it doesn't get called more than once, and there's no way to change the code paths around to prevent it otherwise, we can use the defer callbacks system that I added to #535, when it gets merged.
2021-01-11 04:39:19 +01:00
savestatsandsettings();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Condense indentation levels of else-if chain in "play" menu Previously, the code looked something like: else { if (...) {...} else { if (...) {...} else { etc. } } And kept indenting every time there was an else-if. This commit puts all else-ifs on the same indentation level, so it doesn't slowly push the code to the right.
2020-04-15 21:11:33 +02:00
//Alright then! Flip mode?
else if (unlock[5] && !unlocknotify[18])
{
unlock[18] = true;
unlocknotify[18] = true;
Fix dupe stack frame when creating unlock notif menu The samemenu argument to createmenu() just has to be set to true so another stack frame doesn't get added. Fixes #415.
2020-08-03 06:37:52 +02:00
createmenu(Menu::unlockflipmode, true);
Remove game.savemystats This variable seems to have been intended to make sure game.savestatsandsettings() was called at the end of the frame, or make sure that it didn't get called more than once per frame. I don't see any frame ordering-related reason why it needs to be called specifically at the end of the frame (the function doesn't modify any state), so it's more plausible that it was added to make sure it didn't get called more than one per frame. However, upon further analysis, none of the code paths where game.savemystats is used ever calls or sets game.savemystats more than once, and a majority of the code directly calls game.savestatsandsettings() anyway, so there's no reason for this variable to exist. If we ever need to make sure it doesn't get called more than once, and there's no way to change the code paths around to prevent it otherwise, we can use the defer callbacks system that I added to #535, when it gets merged.
2021-01-11 04:39:19 +01:00
savestatsandsettings();
Condense indentation levels of else-if chain in "play" menu Previously, the code looked something like: else { if (...) {...} else { if (...) {...} else { etc. } } And kept indenting every time there was an else-if. This commit puts all else-ifs on the same indentation level, so it doesn't slowly push the code to the right.
2020-04-15 21:11:33 +02:00
}
//What about the intermission levels?
else if (unlock[7] && !unlocknotify[16])
{
unlock[16] = true;
unlocknotify[16] = true;
Fix dupe stack frame when creating unlock notif menu The samemenu argument to createmenu() just has to be set to true so another stack frame doesn't get added. Fixes #415.
2020-08-03 06:37:52 +02:00
createmenu(Menu::unlockintermission, true);
Remove game.savemystats This variable seems to have been intended to make sure game.savestatsandsettings() was called at the end of the frame, or make sure that it didn't get called more than once per frame. I don't see any frame ordering-related reason why it needs to be called specifically at the end of the frame (the function doesn't modify any state), so it's more plausible that it was added to make sure it didn't get called more than one per frame. However, upon further analysis, none of the code paths where game.savemystats is used ever calls or sets game.savemystats more than once, and a majority of the code directly calls game.savestatsandsettings() anyway, so there's no reason for this variable to exist. If we ever need to make sure it doesn't get called more than once, and there's no way to change the code paths around to prevent it otherwise, we can use the defer callbacks system that I added to #535, when it gets merged.
2021-01-11 04:39:19 +01:00
savestatsandsettings();
Condense indentation levels of else-if chain in "play" menu Previously, the code looked something like: else { if (...) {...} else { if (...) {...} else { etc. } } And kept indenting every time there was an else-if. This commit puts all else-ifs on the same indentation level, so it doesn't slowly push the code to the right.
2020-04-15 21:11:33 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
else
{
Add and use Game::save_exists() This is simply a shorthand for telesummary != "" || quicksummary != "", to make it easier and less error-prone to negate. This improves readability.
2020-04-26 22:41:35 +02:00
if (save_exists())
Make "start game" goto play menu if any unlocks, even if saves deleted This commit fixes a slightly frustrating thing where if you start a new game, and then exit before saving, "start game" will always take you to a new game, even though you have unlocked things like the Secret Lab or Time Trials. Now, if you select "new game" (only possible if you have something unlocked), then quit before saving, "start game" will still take you to the play menu, but "continue" is replaced with "start" and "new game" is gone.
2020-04-26 22:09:56 +02:00
{
option("continue");
}
else
{
Rename "start" option to "new game" By popular request. Aizu said that "start" looks ugly since it's too short compared to the rest of the menu options.
2020-05-06 21:37:50 +02:00
option("new game");
Make "start game" goto play menu if any unlocks, even if saves deleted This commit fixes a slightly frustrating thing where if you start a new game, and then exit before saving, "start game" will always take you to a new game, even though you have unlocked things like the Secret Lab or Time Trials. Now, if you select "new game" (only possible if you have something unlocked), then quit before saving, "start game" will still take you to the play menu, but "continue" is replaced with "start" and "new game" is gone.
2020-04-26 22:09:56 +02:00
}
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
//ok, secret lab! no notification, but test:
if (unlock[8])
{
Move Secret Lab nocompetitive check to Super Gravitron It turns out, despite the game attempting to prevent you from using invincibility or slowdown in the Super Gravitron by simply preventing you from entering the Secret Lab from the menu, it's still possible to enter the Super Gravitron with it anyways. Just have invincibility or slowdown (or both!) enabled, enter the game normally, and talk to Victoria when you have 20 trinkets, to start the epilogue cutscene. Yeah, that's a pretty big gaping hole right there... It's also possible to do a trick that speedrunners use called telejumping to the Secret Lab to bypass the invincibility/slowdown check, too. So rather than single-case patch both of these, I'm going to fix it as generally as possible, by moving the invincibility/slowdown check to the gamestate that starts the Super Gravitron, gamestate 9. If you have invincibility/slowdown enabled, you immediately get sent back to the Secret Lab. However, this check is ignored in custom levels, because custom levels may want to use the Super Gravitron and let players have invincibility/slowdown while doing so (and there are in fact custom levels out in the wild that use the Super Gravitron; it was like one of the first things done when people discovered internal scripting). No message pops up when the game sends you back to the Secret Lab, but no message popped up when the Secret Lab menu option was disabled previously in the first place, so I haven't made anything WORSE, per se. A nice effect of this is that you can have invincibility/slowdown enabled and still be able to go to the Secret Lab from the menu. This is useful if you just want to check your trophies and leave, without having to go out of your way to disable invincibility/slowdown just to go inside.
2021-05-04 03:57:13 +02:00
option("secret lab");
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
}
Condense indentation levels of else-if chain in "play" menu Previously, the code looked something like: else { if (...) {...} else { if (...) {...} else { etc. } } And kept indenting every time there was an else-if. This commit puts all else-ifs on the same indentation level, so it doesn't slowly push the code to the right.
2020-04-15 21:11:33 +02:00
option("play modes");
Add and use Game::save_exists() This is simply a shorthand for telesummary != "" || quicksummary != "", to make it easier and less error-prone to negate. This improves readability.
2020-04-26 22:41:35 +02:00
if (save_exists())
Make "start game" goto play menu if any unlocks, even if saves deleted This commit fixes a slightly frustrating thing where if you start a new game, and then exit before saving, "start game" will always take you to a new game, even though you have unlocked things like the Secret Lab or Time Trials. Now, if you select "new game" (only possible if you have something unlocked), then quit before saving, "start game" will still take you to the play menu, but "continue" is replaced with "start" and "new game" is gone.
2020-04-26 22:09:56 +02:00
{
option("new game");
}
Condense indentation levels of else-if chain in "play" menu Previously, the code looked something like: else { if (...) {...} else { if (...) {...} else { etc. } } And kept indenting every time there was an else-if. This commit puts all else-ifs on the same indentation level, so it doesn't slowly push the code to the right.
2020-04-15 21:11:33 +02:00
option("return");
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
if (unlock[8])
{
menuyoff = -30;
}
else
{
menuyoff = -40;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Move temp int off of Game This temp variable isn't used anywhere else, and even if it was it's set to something every time it's used, so there's no risk of this commit breaking any backwards compatibility.
2020-04-17 01:08:56 +02:00
}
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
case Menu::unlocktimetrial:
case Menu::unlocktimetrials:
case Menu::unlocknodeathmode:
case Menu::unlockintermission:
case Menu::unlockflipmode:
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
option("continue");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 70;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::newgamewarning:
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
option("start new game");
option("return to menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 64;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::playmodes:
Factor out slowdown/invincibility conds to function This factors out the slowdown and invincibility conditionals to a function. This means less copy-pasted code, and it also conveys intent (that we don't want to allow competitive options if we have either of these cheats enabled). This function isn't implemented in the header because then we would have to include Map.h for map.invincibility, and transitive includes are evil. Although, map.invincibility ought to be on Game instead (it was only mapclass due to 2.2-and-previous argument passing), but that's a bunch of variable reshuffling that can be done later.
2021-05-04 03:29:23 +02:00
option("time trials", !nocompetitive());
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
option("intermissions", unlock[16]);
Factor out slowdown/invincibility conds to function This factors out the slowdown and invincibility conditionals to a function. This means less copy-pasted code, and it also conveys intent (that we don't want to allow competitive options if we have either of these cheats enabled). This function isn't implemented in the header because then we would have to include Map.h for map.invincibility, and transitive includes are evil. Although, map.invincibility ought to be on Game instead (it was only mapclass due to 2.2-and-previous argument passing), but that's a bunch of variable reshuffling that can be done later.
2021-05-04 03:29:23 +02:00
option("no death mode", unlock[17] && !nocompetitive());
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
option("flip mode", unlock[18]);
option("return to play menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 8;
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
maxspacing = 20;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::intermissionmenu:
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
option("play intermission 1");
option("play intermission 2");
option("return to play menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = -35;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::playint1:
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
option("Vitellary");
option("Vermilion");
option("Verdigris");
option("Victoria");
option("return");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 10;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::playint2:
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
option("Vitellary");
option("Vermilion");
option("Verdigris");
option("Victoria");
option("return");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 10;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::continuemenu:
Fix being able to mismatch summary and menu color You were able to mismatch the color of the quicksave/telesave summary and the text/background by pressing Esc when in the "continue" menu, then pressing ACTION on "no, return". This commit fixes that bug by putting the map.settowercolour(3) inside the Menu::continuemenu creation code itself. However, since the Menu::youwannaquit code does map.nexttowercolour() right after it does the game.createmenu(), we also need to put the map.nexttowercolour() before the game.createmenu() beforehand so it doesn't mess up the cyan color that Menu::continuemenu sets. Additionally, I removed the map.settowercolour() from the input handling of Menu::play, as it's superfluous.
2020-04-17 04:52:39 +02:00
map.settowercolour(3);
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
option("continue from teleporter");
option("continue from quicksave");
option("return to play menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 20;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::startnodeathmode:
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
option("disable cutscenes");
option("enable cutscenes");
option("return to play menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 40;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::gameover:
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menucountdown = 120;
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
menudest=Menu::gameover2;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::gameover2:
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
option("return to play menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 80;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::unlockmenutrials:
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
option("space station 1", !unlock[9]);
option("the laboratory", !unlock[10]);
option("the tower", !unlock[11]);
option("space station 2", !unlock[12]);
option("the warp zone", !unlock[13]);
option("the final level", !unlock[14]);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
option("return to unlock menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 0;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::timetrials:
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
option(unlock[9] ? "space station 1" : "???", unlock[9]);
option(unlock[10] ? "the laboratory" : "???", unlock[10]);
option(unlock[11] ? "the tower" : "???", unlock[11]);
option(unlock[12] ? "space station 2" : "???", unlock[12]);
option(unlock[13] ? "the warp zone" : "???", unlock[13]);
option(unlock[14] ? "the final level" : "???", unlock[14]);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
option("return to play menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 0;
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
maxspacing = 15;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::nodeathmodecomplete:
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menucountdown = 90;
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
menudest = Menu::nodeathmodecomplete2;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::nodeathmodecomplete2:
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
option("return to play menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 70;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::timetrialcomplete:
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menucountdown = 90;
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
menudest=Menu::timetrialcomplete2;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::timetrialcomplete2:
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menucountdown = 60;
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
menudest=Menu::timetrialcomplete3;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::timetrialcomplete3:
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
option("return to play menu");
option("try again");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 70;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
case Menu::gamecompletecontinue:
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
option("return to play menu");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = 70;
Turn game.currentmenuname "else-if"s into case-switches Much more stylistic, you don't need to repeat "game.currentmenuname" for each case, and you don't need to deal with the dangling first "if" that doesn't have an "else".
2020-04-17 00:19:17 +02:00
break;
Add error messages for failed writes to disk of settings Changing settings would most of the time attempt to save unlock.vvv and now also settings.vvv, but there would be no feedback whether the files have been saved successfully or not. Now, if saving fails when changing settings in the menu, a warning message will be shown. The setting will still be applied of course, but the user will be informed it couldn't be saved. This message can be silenced until the game is restarted, because I can imagine this could get very annoying when someone already knows their settings aren't writeable. Also, some options didn't even save settings in the first place. These are turning off invincibility, and by coincidence precisely all the options in the advanced options menu. I made sure these options now do so.
2020-11-22 03:10:26 +01:00
case Menu::errorsavingsettings:
option("ok");
option("silence");
menuyoff = 10;
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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
// Automatically center the menu. We must check the width of the menu with the initial horizontal spacing.
Document menu width limit better The reason for the menu width to be limited to 272 pixels was rather undocumented in the code, now the comment explains more about it.
2020-06-29 23:18:33 +02:00
// If it's too wide, reduce the horizontal spacing by 5 and retry.
// Try to limit the menu width to 272 pixels: 320 minus 16*2 for square brackets, minus 8*2 padding.
// The square brackets fall outside the menu width (i.e. selected menu options are printed 16 pixels to the left)
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
bool done_once = false;
int menuwidth = 0;
Correct minimum horizontal spacing check It should've checked the final spacing and not the intermediate maximum value. I had changed some things around, and now the minimum spacing was 5 instead of 0 by mistake.
2020-06-29 02:58:38 +02:00
for (; !done_once || (menuwidth > 272 && menuspacing > 0); maxspacing -= 5)
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
{
done_once = true;
menuspacing = maxspacing;
menuwidth = 0;
for (size_t i = 0; i < menuoptions.size(); i++)
{
int width = i*menuspacing + graphics.len(menuoptions[i].text);
if (width > menuwidth)
menuwidth = width;
}
}
menuxoff = (320-menuwidth)/2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::deletequick(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix deletequick() and deletetele() not deleting their files The problem here is that we're directly using the C stdio library, instead of using PHYSFS's stuff. So I've added a function FILESYSTEM_delete() that does exactly that.
2020-04-26 22:22:26 +02:00
if( !FILESYSTEM_delete( "saves/qsave.vvv" ) )
puts("Error deleting saves/qsave.vvv");
Don't clear telesummary/quicksummary if delete unsuccessful Otherwise the game will think the saves are gone even though they still exist.
2020-04-26 22:15:38 +02:00
else
quicksummary = "";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::deletetele(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix deletequick() and deletetele() not deleting their files The problem here is that we're directly using the C stdio library, instead of using PHYSFS's stuff. So I've added a function FILESYSTEM_delete() that does exactly that.
2020-04-26 22:22:26 +02:00
if( !FILESYSTEM_delete( "saves/tsave.vvv" ) )
puts("Error deleting saves/tsave.vvv");
Don't clear telesummary/quicksummary if delete unsuccessful Otherwise the game will think the saves are gone even though they still exist.
2020-04-26 22:15:38 +02:00
else
telesummary = "";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::swnpenalty(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//set the SWN clock back to the closest 5 second interval
if (swntimer <= 150)
{
swntimer += 8;
if (swntimer > 150) swntimer = 150;
}
else if (swntimer <= 300)
{
swntimer += 8;
if (swntimer > 300) swntimer = 300;
}
else if (swntimer <= 450)
{
swntimer += 8;
if (swntimer > 450) swntimer = 450;
}
else if (swntimer <= 600)
{
swntimer += 8;
if (swntimer > 600) swntimer = 600;
}
else if (swntimer <= 750)
{
swntimer += 8;
if (swntimer > 750) swntimer = 750;
}
else if (swntimer <= 900)
{
swntimer += 8;
if (swntimer > 900) swntimer = 900;
}
else if (swntimer <= 1050)
{
swntimer += 8;
if (swntimer > 1050) swntimer = 1050;
}
else if (swntimer <= 1200)
{
swntimer += 8;
if (swntimer > 1200) swntimer = 1200;
}
else if (swntimer <= 1350)
{
swntimer += 8;
if (swntimer > 1350) swntimer = 1350;
}
else if (swntimer <= 1500)
{
swntimer += 8;
if (swntimer > 1500) swntimer = 1500;
}
else if (swntimer <= 1650)
{
swntimer += 8;
if (swntimer > 1650) swntimer = 1650;
}
else if (swntimer <= 1800)
{
swntimer += 8;
if (swntimer > 1800) swntimer = 1800;
}
else if (swntimer <= 2100)
{
swntimer += 8;
if (swntimer > 2100) swntimer = 2100;
}
else if (swntimer <= 2400)
{
swntimer += 8;
if (swntimer > 2400) swntimer = 2400;
}
}
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 Game::crewrescued(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use for-loop in Game::crewrescued() It's better to not use an STL function here.
2020-04-10 01:01:53 +02:00
int temp = 0;
Turn crew rescued/mood vectors into arrays Since they're always fixed-size, they don't need to be dynamically-sized vectors. entityclass::customcrewmoods is now a proper bool instead of an int now, and I replaced the hardcoded constant 6 with a static const int Game attribute to make it easier to change.
2020-07-03 03:10:52 +02:00
for (size_t i = 0; i < SDL_arraysize(crewstats); i++)
Use for-loop in Game::crewrescued() It's better to not use an STL function here.
2020-04-10 01:01:53 +02:00
{
if (crewstats[i])
{
temp++;
}
}
return temp;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::resetgameclock(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
frames = 0;
seconds = 0;
minutes = 0;
hours = 0;
}
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
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 Game::trinkets(void)
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
{
Don't use std::count() in Game::trinkets() The less STL, the better.
2020-04-10 01:17:11 +02:00
int temp = 0;
Turn obj.collect and obj.customcollect into plain arrays Since they're always fixed-size, there's no need for them to be vectors. Also added an INBOUNDS_ARR() macro to do bounds checks with plain arrays.
2020-07-03 04:17:32 +02:00
for (size_t i = 0; i < SDL_arraysize(obj.collect); i++)
Don't use std::count() in Game::trinkets() The less STL, the better.
2020-04-10 01:17:11 +02:00
{
if (obj.collect[i])
{
temp++;
}
}
return temp;
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
}
Don't use separate variable for number of collected crewmates Same as previous commit, except for crewmates in custom levels instead.
2020-04-07 08:53:32 +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
int Game::crewmates(void)
Don't use separate variable for number of collected crewmates Same as previous commit, except for crewmates in custom levels instead.
2020-04-07 08:53:32 +02:00
{
Don't use std::count() in Game::crewmates() The less STL usage, the better.
2020-04-10 01:17:52 +02:00
int temp = 0;
Turn obj.collect and obj.customcollect into plain arrays Since they're always fixed-size, there's no need for them to be vectors. Also added an INBOUNDS_ARR() macro to do bounds checks with plain arrays.
2020-07-03 04:17:32 +02:00
for (size_t i = 0; i < SDL_arraysize(obj.customcollect); i++)
Don't use std::count() in Game::crewmates() The less STL usage, the better.
2020-04-10 01:17:52 +02:00
{
if (obj.customcollect[i])
{
temp++;
}
}
return temp;
Don't use separate variable for number of collected crewmates Same as previous commit, except for crewmates in custom levels instead.
2020-04-07 08:53:32 +02:00
}
Add function Game::anything_unlocked() This will be a useful shorthand to ask "do we have the Secret Lab, or any Time Trial, or Intermission replays, or No Death Mode, or Flip Mode unlocked?"
2020-04-26 21:43:30 +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 Game::anything_unlocked(void)
Add function Game::anything_unlocked() This will be a useful shorthand to ask "do we have the Secret Lab, or any Time Trial, or Intermission replays, or No Death Mode, or Flip Mode unlocked?"
2020-04-26 21:43:30 +02:00
{
Turn unlock/unlocknotify into plain arrays They're always fixed-size, so there's no need to them to be a dynamic vector. I changed their type to `bool` too because they don't need to be `int`s. Also, I replaced the hardcoded 25 constant with at least a name, in case people want to change it in the future.
2020-07-03 01:45:22 +02:00
for (size_t i = 0; i < SDL_arraysize(unlock); i++)
Add function Game::anything_unlocked() This will be a useful shorthand to ask "do we have the Secret Lab, or any Time Trial, or Intermission replays, or No Death Mode, or Flip Mode unlocked?"
2020-04-26 21:43:30 +02:00
{
if (unlock[i] &&
(i == 8 // Secret Lab
Fix Game::anything_unlocked() always evaluating to true Whoops.
2020-06-28 11:12:56 +02:00
|| (i >= 9 && i <= 14) // any Time Trial
Add function Game::anything_unlocked() This will be a useful shorthand to ask "do we have the Secret Lab, or any Time Trial, or Intermission replays, or No Death Mode, or Flip Mode unlocked?"
2020-04-26 21:43:30 +02:00
|| i == 16 // Intermission replays
|| i == 17 // No Death Mode
|| i == 18)) // Flip Mode
{
return true;
}
}
return false;
}
Add and use Game::save_exists() This is simply a shorthand for telesummary != "" || quicksummary != "", to make it easier and less error-prone to negate. This improves readability.
2020-04-26 22:41:35 +02:00
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 Game::save_exists(void)
Add and use Game::save_exists() This is simply a shorthand for telesummary != "" || quicksummary != "", to make it easier and less error-prone to negate. This improves readability.
2020-04-26 22:41:35 +02:00
{
return telesummary != "" || quicksummary != "";
}
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
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 Game::quittomenu(void)
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
2020-05-07 23:38:19 +02:00
{
gamestate = TITLEMODE;
graphics.fademode = 4;
Properly camel-case FILESYSTEM_[un]mountassets() They are now camel-cased to be consistent with the rest of the filesystem functions.
2021-04-03 21:48:47 +02:00
FILESYSTEM_unmountAssets();
Reset cliplaytest when exiting to menu and check it when loading This fixes a bug where quitting to the menu from command-line playtesting with -playassets specified would always use those assets when loading back in to any custom level. This also fixes loading in to a custom level quicksave always using the command-line playtesting arguments instead of using the actual quicksave.
2021-04-14 05:00:07 +02:00
cliplaytest = false;
Move title usages of towerbg to titlebg With the previous commit in place, we can now simply move some usages of the previous towerbg to use a separate object instead. That way, we don't have to mess with a monolithic state, or some better way to phrase what I just said, and we instead have two separate objects that can coexist side-by-side.
2020-11-03 00:23:53 +01:00
graphics.titlebg.tdrawback = true;
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
2020-05-07 23:38:19 +02:00
graphics.flipmode = false;
//Don't be stuck on the summary screen,
//or "who do you want to play the level with?"
//or "do you want cutscenes?"
//or the confirm-load-quicksave menu
Move script.hardreset() to after quit to menu This cleans up a whole lot of kludge variables, because this aggressive hardreset() right as ACTION is pressed doesn't do anyone any favors. This aggressive hardreset() was probably here because of the whole fact that exiting to the menu uses Terry's State Machine, to minimize the chances of interruption, but it actually causes more issues and allows towers to interrupt the fadeout. And we should fix the root cause (the usage of the state machine) instead of patching together some kludge.
2020-05-07 23:54:39 +02:00
if (intimetrial)
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
2020-05-07 23:38:19 +02:00
{
returntomenu(Menu::timetrials);
}
Move script.hardreset() to after quit to menu This cleans up a whole lot of kludge variables, because this aggressive hardreset() right as ACTION is pressed doesn't do anyone any favors. This aggressive hardreset() was probably here because of the whole fact that exiting to the menu uses Terry's State Machine, to minimize the chances of interruption, but it actually causes more issues and allows towers to interrupt the fadeout. And we should fix the root cause (the usage of the state machine) instead of patching together some kludge.
2020-05-07 23:54:39 +02:00
else if (inintermission)
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
2020-05-07 23:38:19 +02:00
{
returntomenu(Menu::intermissionmenu);
}
Move script.hardreset() to after quit to menu This cleans up a whole lot of kludge variables, because this aggressive hardreset() right as ACTION is pressed doesn't do anyone any favors. This aggressive hardreset() was probably here because of the whole fact that exiting to the menu uses Terry's State Machine, to minimize the chances of interruption, but it actually causes more issues and allows towers to interrupt the fadeout. And we should fix the root cause (the usage of the state machine) instead of patching together some kludge.
2020-05-07 23:54:39 +02:00
else if (nodeathmode)
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
2020-05-07 23:38:19 +02:00
{
returntomenu(Menu::playmodes);
}
Move script.hardreset() to after quit to menu This cleans up a whole lot of kludge variables, because this aggressive hardreset() right as ACTION is pressed doesn't do anyone any favors. This aggressive hardreset() was probably here because of the whole fact that exiting to the menu uses Terry's State Machine, to minimize the chances of interruption, but it actually causes more issues and allows towers to interrupt the fadeout. And we should fix the root cause (the usage of the state machine) instead of patching together some kludge.
2020-05-07 23:54:39 +02:00
else if (map.custommode)
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
2020-05-07 23:38:19 +02:00
{
Clean up all exit paths to the menu to use common code There are multiple different exit paths to the main menu. In 2.2, they all had a bunch of copy-pasted code. In 2.3 currently, most of them use game.quittomenu(), but there are some stragglers that still use hand-copied code. This is a bit of a problem, because all exit paths should consistently have FILESYSTEM_unmountassets(), as part of the 2.3 feature of per-level custom assets. Furthermore, most (but not all) of the paths call script.hardreset() too, and some of the stragglers don't. So there could be something persisting through to the title screen (like a really long flash/shake timer) that could only persist if exiting to the title screen through those paths. But, actually, it seems like there's a good reason for some of those to not call script.hardreset() - namely, dying or completing No Death Mode and completing a Time Trial presents some information onscreen that would get reset by script.hardreset(), so I'll fix that in a later commit. So what I've done for this commit is found every exit path that didn't already use game.quittomenu(), and made them use game.quittomenu(). As well, some of them had special handling that existed on top of them already having a corresponding entry in game.quittomenu() (but the path would take the special handling because it never did game.quittomenu()), so I removed that special handling as well (e.g. exiting from a custom level used returntomenu(Menu::levellist) when quittomenu() already had that same returntomenu()). The menu that exiting from the level editor returns to is now handled in game.quittomenu() as well, where the map.custommode branch now also checks for map.custommodeforreal. Unfortunately, it seems like entering the level editor doesn't properly initialize map.custommode, so entering the level editor now initializes map.custommode, too. I've also taken the music.play(6) out of game.quittomenu(), because not all exit paths immediately play Presenting VVVVVV, so all exit paths that DO immediately play Presenting VVVVVV now have music.play(6) special-cased for them, which is fine enough for me. Here is the list of all exit paths to the menu: - Exiting through the pause menu (without glitchrunner mode) - Exiting through the pause menu (with glitchrunner mode) - Completing a custom level - Completing a Time Trial - Dying in No Death Mode - Completing No Death Mode - Completing an Intermission replay - Exiting from the level editor - Completing the main game
2021-01-07 23:20:37 +01:00
if (map.custommodeforreal)
{
returntomenu(Menu::levellist);
}
else
{
//Returning from editor
returntomenu(Menu::playerworlds);
}
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
2020-05-07 23:38:19 +02:00
}
else if (save_exists() || anything_unlocked())
{
returntomenu(Menu::play);
Select "continue" if returning from new game when having had a save If you started a new game while having had a save (meaning you selectedd "new game" while it wasn't in the same position as "continue"), then saved and quit, your cursor will now end up at "continue" instead of "new game". (If you didn't save, then your cursor would be out-of-bounds and end up at position 0 anyway.)
2020-05-19 02:49:35 +02:00
if (!insecretlab)
{
//Select "continue"
currentmenuoption = 0;
}
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
2020-05-07 23:38:19 +02:00
}
else
{
createmenu(Menu::mainmenu);
}
Move script.hardreset() to after quit to menu This cleans up a whole lot of kludge variables, because this aggressive hardreset() right as ACTION is pressed doesn't do anyone any favors. This aggressive hardreset() was probably here because of the whole fact that exiting to the menu uses Terry's State Machine, to minimize the chances of interruption, but it actually causes more issues and allows towers to interrupt the fadeout. And we should fix the root cause (the usage of the state machine) instead of patching together some kludge.
2020-05-07 23:54:39 +02:00
script.hardreset();
Move quit to menu to Game::quittomenu() I don't want the quit code to only be in the state machine, but I'll keep the gamestate around for compatibility reasons (there are custom levels that directly use gamestate 80 to quit to the menu).
2020-05-07 23:38:19 +02:00
}
Move return to lab code to Game::returntolab() Again, I'll keep gamestate 96 and 97 for compatibility reasons, but ultimately we shouldn't be using gamestates to return to the lab.
2020-05-08 00:17:04 +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 Game::returntolab(void)
Move return to lab code to Game::returntolab() Again, I'll keep gamestate 96 and 97 for compatibility reasons, but ultimately we shouldn't be using gamestates to return to the lab.
2020-05-08 00:17:04 +02:00
{
gamestate = GAMEMODE;
graphics.fademode = 4;
Directly do returntolab code instead of relying on a script Having to rely on a script means the fade out wouldn't be self-contained in MAPMODE, which could cause a small issue where you could die during the return to the lab. But that issue is now fixed. There's no need to use the script, and anyway the endcutscene() and untilbars() in said script don't do anything because there are no cutscene bars in the first place, so no need to worry about those.
2020-05-08 00:36:38 +02:00
map.gotoroom(119, 107);
int player = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(player, obj.entities))
Directly do returntolab code instead of relying on a script Having to rely on a script means the fade out wouldn't be self-contained in MAPMODE, which could cause a small issue where you could die during the return to the lab. But that issue is now fixed. There's no need to use the script, and anyway the endcutscene() and untilbars() in said script don't do anything because there are no cutscene bars in the first place, so no need to worry about those.
2020-05-08 00:36:38 +02:00
{
obj.entities[player].xp = 132;
obj.entities[player].yp = 137;
}
gravitycontrol = 0;
savepoint = 0;
saverx = 119;
savery = 107;
savex = 132;
savey = 137;
savegc = 0;
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(player, obj.entities))
Directly do returntolab code instead of relying on a script Having to rely on a script means the fade out wouldn't be self-contained in MAPMODE, which could cause a small issue where you could die during the return to the lab. But that issue is now fixed. There's no need to use the script, and anyway the endcutscene() and untilbars() in said script don't do anything because there are no cutscene bars in the first place, so no need to worry about those.
2020-05-08 00:36:38 +02:00
{
savedir = obj.entities[player].dir;
}
music.play(11);
Move return to lab code to Game::returntolab() Again, I'll keep gamestate 96 and 97 for compatibility reasons, but ultimately we shouldn't be using gamestates to return to the lab.
2020-05-08 00:17:04 +02:00
}
Abstract returning-to-editor code to Game::returntoeditor() This way I can easily move it around without moving around a bunch of lines of code.
2020-05-09 21:35:17 +02:00
#if !defined(NO_CUSTOM_LEVELS)
Remove game.shouldreturntoeditor in favor of using defer callback game.shouldreturntoeditor was added to fix a frame ordering issue that was causing a bug where if you started playtesting in a room with a horizontal/vertical warp background, and exited playtesting in a different room that also had a horizontal/vertical warp background and which was different, then the background of the room you exited in would slowly scroll offscreen, when you re-entered the editor, instead of the background consisting entirely of the actual background of the room. Namely, the issue was that the game would render one more frame of GAMEMODE after graphics.backgrounddrawn got set to false, and re-set it to true, thus negating the background redraw, so the editor background would be incorrect. With defer callbacks, we can now just use a couple lines of code, instead of having to add an extra kludge variable and putting handling for it all over the code.
2021-01-10 23:48:25 +01:00
static void resetbg(void)
{
graphics.backgrounddrawn = false;
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void Game::returntoeditor(void)
Abstract returning-to-editor code to Game::returntoeditor() This way I can easily move it around without moving around a bunch of lines of code.
2020-05-09 21:35:17 +02:00
{
Clean up and prevent unnecessary qualifiers to self By "unnecessary qualifiers to self", I mean something like using the 'game.' qualifier for a variable on the Game class when you're inside a function on the Game class itself. This patch is to enforce consistency as most of the code doesn't have these unnecessary qualifiers. To prevent further unnecessary qualifiers to self, I made it so the extern in each header file can be omitted by using a define. That way, if someone writes something referring to 'game.' on a Game function, there will be a compile error. However, if you really need to have a reference to the global name, and you're within the same .cpp file as the implementation of that object, you can just do the extern at the function-level. A good example of this is editorinput()/editorrender()/editorlogic() in editor.cpp. In my opinion, they should probably be split off into their own separate file because editor.cpp is getting way too big, but this will do for now.
2020-09-28 04:15:06 +02:00
gamestate = EDITORMODE;
Abstract returning-to-editor code to Game::returntoeditor() This way I can easily move it around without moving around a bunch of lines of code.
2020-05-09 21:35:17 +02:00
Use .clear() when removing text boxes in reset functions graphics.textbox.clear() should be used instead of graphics.textboxremove() or graphics.textboxremovefast(), because even with graphics.textboxremovefast(), you'll still have to process at least one frame of GAMEMODE logic before the text boxes are actually properly removed, and this caused a 1-frame glitch when exiting playtesting with text boxes on-screen and then re-entering playtesting. Technically I could've only fixed it in Game::returntoeditor(), but I wanted to be safe, so I also fixed it in scriptclass::hardreset(), too.
2020-07-11 09:10:06 +02:00
graphics.textbox.clear();
Clean up and prevent unnecessary qualifiers to self By "unnecessary qualifiers to self", I mean something like using the 'game.' qualifier for a variable on the Game class when you're inside a function on the Game class itself. This patch is to enforce consistency as most of the code doesn't have these unnecessary qualifiers. To prevent further unnecessary qualifiers to self, I made it so the extern in each header file can be omitted by using a define. That way, if someone writes something referring to 'game.' on a Game function, there will be a compile error. However, if you really need to have a reference to the global name, and you're within the same .cpp file as the implementation of that object, you can just do the extern at the function-level. A good example of this is editorinput()/editorrender()/editorlogic() in editor.cpp. In my opinion, they should probably be split off into their own separate file because editor.cpp is getting way too big, but this will do for now.
2020-09-28 04:15:06 +02:00
hascontrol = true;
advancetext = false;
completestop = false;
state = 0;
Abstract returning-to-editor code to Game::returntoeditor() This way I can easily move it around without moving around a bunch of lines of code.
2020-05-09 21:35:17 +02:00
graphics.showcutscenebars = false;
graphics.fademode = 0;
Set ed.keydelay to 6 when returning to editor This fixes an annoying bug where if you use Up or Down to press ACTION on the "All crewmates rescued!" dialogue whenever you rescue the last crewmate during playtesting, it'll move you to the room above or below you. This is because ed.keydelay isn't set to 6 (which is the standard value that it gets set to whenever you press most keys in the editor), but now it is.
2020-07-11 09:04:54 +02:00
ed.keydelay = 6;
Set ed.settingskey to true when returning to editor This fixes a bug where the settings menu would immediately be brought up if you used Esc to exit playtesting, unless you were an incredible ninja and only pressed it for exactly one frame.
2020-07-11 09:09:02 +02:00
ed.settingskey = true;
Reset ed.notedelay when exiting playtesting It's not very useful to show a message that was relevant only when you started playtesting.
2020-07-11 09:27:00 +02:00
ed.oldnotedelay = 0;
ed.notedelay = 0;
Reset ed.roomnamehide to 0 when exiting playtesting Now if your cursor was at the bottom of the screen when you entered playtesting but then was moved to the top during playtesting, when you exit, the roomname won't instantly disappear and then sheepishly rise back up again. And if your cursor was at the bottom of the screen when you entered playtesting, and exited still being that way, the roomname will rise back down again and won't instantly disappear. Both of these behaviors make the roomname movement much more continuous than it was previously, and it feels smoother and less janky.
2020-07-11 09:39:09 +02:00
ed.roomnamehide = 0;
Set ed.keydelay to 6 when returning to editor This fixes an annoying bug where if you use Up or Down to press ACTION on the "All crewmates rescued!" dialogue whenever you rescue the last crewmate during playtesting, it'll move you to the room above or below you. This is because ed.keydelay isn't set to 6 (which is the standard value that it gets set to whenever you press most keys in the editor), but now it is.
2020-07-11 09:04:54 +02:00
Remove game.shouldreturntoeditor in favor of using defer callback game.shouldreturntoeditor was added to fix a frame ordering issue that was causing a bug where if you started playtesting in a room with a horizontal/vertical warp background, and exited playtesting in a different room that also had a horizontal/vertical warp background and which was different, then the background of the room you exited in would slowly scroll offscreen, when you re-entered the editor, instead of the background consisting entirely of the actual background of the room. Namely, the issue was that the game would render one more frame of GAMEMODE after graphics.backgrounddrawn got set to false, and re-set it to true, thus negating the background redraw, so the editor background would be incorrect. With defer callbacks, we can now just use a couple lines of code, instead of having to add an extra kludge variable and putting handling for it all over the code.
2021-01-10 23:48:25 +01:00
DEFER_CALLBACK(resetbg);
Abstract returning-to-editor code to Game::returntoeditor() This way I can easily move it around without moving around a bunch of lines of code.
2020-05-09 21:35:17 +02:00
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)];
}
}
Move title usages of towerbg to titlebg With the previous commit in place, we can now simply move some usages of the previous towerbg to use a separate object instead. That way, we don't have to mess with a monolithic state, or some better way to phrase what I just said, and we instead have two separate objects that can coexist side-by-side.
2020-11-03 00:23:53 +01:00
graphics.titlebg.scrolldir = 0;
Abstract returning-to-editor code to Game::returntoeditor() This way I can easily move it around without moving around a bunch of lines of code.
2020-05-09 21:35:17 +02:00
}
#endif
Move returning to pause menu code to separate function This code is getting a bit more complicated now, we should maybe stop copy-pasting it everywhere.
2020-06-23 02:26:45 +02:00
Fix 1-frame text glitch returning to pause menu from in-game options The new loop order introduces a glitch where the menu would display whichever menu was saved to kludge_ingametemp for 1 frame right as the user returned to the pause menu. This happened because the game.returntomenu() happens in titleinput(), which comes before titlerender(). To fix this, we just need to defer it to the end of the frame.
2021-01-13 05:11:50 +01:00
static void returntoingametemp(void)
{
extern Game game;
game.returntomenu(game.kludge_ingametemp);
}
Fix 1-frame text glitch when returning to editor settings from options The returnmenu() needs to be deferred until the end of the frame.
2021-03-19 05:11:52 +01:00
#if !defined(NO_CUSTOM_LEVELS) && !defined(NO_EDITOR)
static void returntoedsettings(void)
{
extern Game game;
game.returntomenu(Menu::ed_settings);
}
#endif
Fix 1-frame background glitch when returning from in-game options The background would change for 1 frame before sending you back to the pause menu or editor settings. The map.nexttowercolour() call needs to be deferred until the end of the frame.
2021-03-19 05:12:55 +01:00
static void nextbgcolor(void)
{
map.nexttowercolour();
}
Set fademode to temp 0 when going to in-game options While I've decoupled fademode from gamemode starting, being faded out on the title screen results in a black screen and you being unable to make any input. So we'll need to store the current fademode in a temporary variable when going to in-game options, then put it back when we return to the pause menu. Yes, you can turn on glitchrunner mode during the in-game options, and then immediately return to the pause menu to instantly go back to the title screen; this is intended. Due to frame ordering, putting the fademode back needs to be deferred to the end of the frame to prevent a 1-frame flicker. It's actually sufficient enough to do this temporary fademode storage to fix the whole thing, but I also decided to decouple fademode and gamemode starting just to be sure.
2021-03-20 07:23:18 +01:00
static void setfademode(void)
{
graphics.fademode = graphics.ingame_fademode;
}
Fix 1-frame glitch returning from in-game options with Flip Mode on If you had Flip Mode enabled when exiting from in-game options, the game would flash the in-game options menu as flipped for 1 frame before returning to the pause menu. To fix this, just defer the Flip Mode variable assignment to be done at the end of the frame.
2021-05-12 05:03:11 +02:00
static void setflipmode(void)
{
graphics.flipmode = graphics.setflipmode;
}
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 Game::returntoingame(void)
Move returning to pause menu code to separate function This code is getting a bit more complicated now, we should maybe stop copy-pasting it everywhere.
2020-06-23 02:26:45 +02:00
{
ingame_titlemode = false;
Clean up and prevent unnecessary qualifiers to self By "unnecessary qualifiers to self", I mean something like using the 'game.' qualifier for a variable on the Game class when you're inside a function on the Game class itself. This patch is to enforce consistency as most of the code doesn't have these unnecessary qualifiers. To prevent further unnecessary qualifiers to self, I made it so the extern in each header file can be omitted by using a define. That way, if someone writes something referring to 'game.' on a Game function, there will be a compile error. However, if you really need to have a reference to the global name, and you're within the same .cpp file as the implementation of that object, you can just do the extern at the function-level. A good example of this is editorinput()/editorrender()/editorlogic() in editor.cpp. In my opinion, they should probably be split off into their own separate file because editor.cpp is getting way too big, but this will do for now.
2020-09-28 04:15:06 +02:00
mapheld = true;
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)
if (ingame_editormode)
Fix being able to circumvent not-in-Flip-Mode detection So you get a trophy and achievement for completing the game in Flip Mode. Which begs the question, how does the game know that you've played through the game in Flip Mode the entire way, and haven't switched it off at any point? It looks like if you play normally all the way up until the checkpoint in V, and then turn on Flip Mode, the game won't give you the trophy. What gives? Well, actually, what happens is that every time you press Enter on a teleporter, the game will set flag 73 to true if you're NOT in Flip Mode. Then when Game Complete runs, the game will check if flag 73 is off, and then give you the achievement and trophy accordingly. However, what this means is that you could just save your game before pressing Enter on a teleporter, then quit and go into options, turn on Flip Mode, use the teleporter, then save your game (it's automatically saved since you just used a teleporter), quit and go into options, and turn it off. Then you'd get the Flip Mode trophy even though you haven't actually played the entire game in Flip Mode. Furthermore, in 2.3 you can bring up the pause menu to toggle Flip Mode, so you don't even have to quit to circumvent this detection. To fix both of these exploits, I moved the turning on of flag 73 to starting a new game, loading a quicksave, and loading a telesave (cases 0, 1, and 2 respectively in scriptclass::startgamemode()). I also added a Flip Mode check to the routine that runs whenever you exit an options menu back to the pause menu, so you can't circumvent the detection that way, either.
2020-07-11 01:30:28 +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
ingame_editormode = false;
Fix 1-frame text glitch when returning to editor settings from options The returnmenu() needs to be deferred until the end of the frame.
2021-03-19 05:11:52 +01:00
DEFER_CALLBACK(returntoedsettings);
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
gamestate = EDITORMODE;
ed.settingskey = true;
}
else
#endif
{
Fix 1-frame text glitch returning to pause menu from in-game options The new loop order introduces a glitch where the menu would display whichever menu was saved to kludge_ingametemp for 1 frame right as the user returned to the pause menu. This happened because the game.returntomenu() happens in titleinput(), which comes before titlerender(). To fix this, we just need to defer it to the end of the frame.
2021-01-13 05:11:50 +01:00
DEFER_CALLBACK(returntoingametemp);
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
gamestate = MAPMODE;
Fix 1-frame glitch returning from in-game options with Flip Mode on If you had Flip Mode enabled when exiting from in-game options, the game would flash the in-game options menu as flipped for 1 frame before returning to the pause menu. To fix this, just defer the Flip Mode variable assignment to be done at the end of the frame.
2021-05-12 05:03:11 +02:00
DEFER_CALLBACK(setflipmode);
Set fademode to temp 0 when going to in-game options While I've decoupled fademode from gamemode starting, being faded out on the title screen results in a black screen and you being unable to make any input. So we'll need to store the current fademode in a temporary variable when going to in-game options, then put it back when we return to the pause menu. Yes, you can turn on glitchrunner mode during the in-game options, and then immediately return to the pause menu to instantly go back to the title screen; this is intended. Due to frame ordering, putting the fademode back needs to be deferred to the end of the frame to prevent a 1-frame flicker. It's actually sufficient enough to do this temporary fademode storage to fix the whole thing, but I also decided to decouple fademode and gamemode starting just to be sure.
2021-03-20 07:23:18 +01:00
DEFER_CALLBACK(setfademode);
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 (!map.custommode && !graphics.flipmode)
{
obj.flags[73] = true;
}
Fix being able to circumvent not-in-Flip-Mode detection So you get a trophy and achievement for completing the game in Flip Mode. Which begs the question, how does the game know that you've played through the game in Flip Mode the entire way, and haven't switched it off at any point? It looks like if you play normally all the way up until the checkpoint in V, and then turn on Flip Mode, the game won't give you the trophy. What gives? Well, actually, what happens is that every time you press Enter on a teleporter, the game will set flag 73 to true if you're NOT in Flip Mode. Then when Game Complete runs, the game will check if flag 73 is off, and then give you the achievement and trophy accordingly. However, what this means is that you could just save your game before pressing Enter on a teleporter, then quit and go into options, turn on Flip Mode, use the teleporter, then save your game (it's automatically saved since you just used a teleporter), quit and go into options, and turn it off. Then you'd get the Flip Mode trophy even though you haven't actually played the entire game in Flip Mode. Furthermore, in 2.3 you can bring up the pause menu to toggle Flip Mode, so you don't even have to quit to circumvent this detection. To fix both of these exploits, I moved the turning on of flag 73 to starting a new game, loading a quicksave, and loading a telesave (cases 0, 1, and 2 respectively in scriptclass::startgamemode()). I also added a Flip Mode check to the routine that runs whenever you exit an options menu back to the pause menu, so you can't circumvent the detection that way, either.
2020-07-11 01:30:28 +02:00
}
Fix 1-frame background glitch when returning from in-game options The background would change for 1 frame before sending you back to the pause menu or editor settings. The map.nexttowercolour() call needs to be deferred until the end of the frame.
2021-03-19 05:12:55 +01:00
DEFER_CALLBACK(nextbgcolor);
Move returning to pause menu code to separate function This code is getting a bit more complicated now, we should maybe stop copy-pasting it everywhere.
2020-06-23 02:26:45 +02:00
}
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
void Game::unlockAchievement(const char *name) {
#if !defined(MAKEANDPLAY)
if (!map.custommode) NETWORK_unlockAchievement(name);
#endif
add newline at the end of game.cpp
2020-08-01 22:04:37 +02:00
}
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 Game::mapmenuchange(const int newgamestate)
{
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
prevgamestate = gamestate;
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
gamestate = newgamestate;
graphics.resumegamemode = false;
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
mapheld = true;
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
Fix bringing up map menu during gamemode(teleporter) When gamemode(teleporter) gets run in a script, it brings up a read-only version of the teleporter screen, intended only for displaying rooms on the minimap. However, ever since 2.3 allowed bringing up the map screen during cutscenes (in order to prevent softlocks), bringing up the map screen during this mode would (1) do an unnecessary animation of suddenly switching back to the game and bringing up the menu screen again (even though the menu screen has already been brought up), and (2) would let you close the menu entirely and go back to GAMEMODE, thus unintentionally closing the teleporter screen and kind of ruining the cutscene. To fix this, when you bring up the map screen, it will instead instantly transition to the map screen. And when you bring it down, it will also instantly transition back to the teleporter screen. But that's not all. The previous behavior was actually kind of a nice failsafe, in that if you somehow got stuck in a state where a script ran gamemode(teleporter), but stopped running before it could take you out of that mode by running gamemode(game), then you could return to GAMEMODE yourself by bringing up the map screen and then bringing it back down. So I've made sure to keep that failsafe behavior, only as long as there isn't a script running.
2020-12-29 00:36:32 +01:00
if (prevgamestate == GAMEMODE)
{
graphics.menuoffset = 240;
if (map.extrarow)
{
graphics.menuoffset -= 10;
}
}
else
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
{
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
graphics.menuoffset = 0;
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
}
graphics.oldmenuoffset = graphics.menuoffset;
}
Fix No Death Mode results being reset before being shown This does the same thing as the last commit, but for No Death Mode instead of Time Trials. Whenever you die in No Death Mode, or complete it, all the relevant variables get copied to variables prefixed with 'ndmresult' that never get reset by script.hardreset(), and these variables are what titlerender() use, instead of the "live" ones.
2021-01-08 01:18:07 +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 Game::copyndmresults(void)
Fix No Death Mode results being reset before being shown This does the same thing as the last commit, but for No Death Mode instead of Time Trials. Whenever you die in No Death Mode, or complete it, all the relevant variables get copied to variables prefixed with 'ndmresult' that never get reset by script.hardreset(), and these variables are what titlerender() use, instead of the "live" ones.
2021-01-08 01:18:07 +01:00
{
ndmresultcrewrescued = crewrescued();
ndmresulttrinkets = trinkets();
ndmresulthardestroom = hardestroom;
SDL_memcpy(ndmresultcrewstats, crewstats, sizeof(ndmresultcrewstats));
}
Factor timestep calculation out to Game function This is so we can grab the game's timestep anywhere else in the codebase without copy-pasting it.
2021-04-02 20:50:30 +02:00
static inline int get_framerate(const int slowdown)
{
switch (slowdown)
{
case 30:
return 34;
case 24:
return 41;
case 18:
return 55;
case 12:
return 83;
}
return 34;
}
int Game::get_timestep(void)
{
switch (gamestate)
{
case EDITORMODE:
return 24;
case GAMEMODE:
return get_framerate(slowdown);
default:
return 34;
}
}
Factor out Secret Lab/Time Trial/NDM conds to function They are now factored out to an inline function named incompetitive(). This is so their usage can be changed without having to change each individual one in every place. This also clarifies the intent of using these conditionals (they are for when we're in a "competitive" mode).
2021-05-04 03:22:59 +02:00
bool Game::incompetitive(void)
{
Move Secret Lab nocompetitive check to Super Gravitron It turns out, despite the game attempting to prevent you from using invincibility or slowdown in the Super Gravitron by simply preventing you from entering the Secret Lab from the menu, it's still possible to enter the Super Gravitron with it anyways. Just have invincibility or slowdown (or both!) enabled, enter the game normally, and talk to Victoria when you have 20 trinkets, to start the epilogue cutscene. Yeah, that's a pretty big gaping hole right there... It's also possible to do a trick that speedrunners use called telejumping to the Secret Lab to bypass the invincibility/slowdown check, too. So rather than single-case patch both of these, I'm going to fix it as generally as possible, by moving the invincibility/slowdown check to the gamestate that starts the Super Gravitron, gamestate 9. If you have invincibility/slowdown enabled, you immediately get sent back to the Secret Lab. However, this check is ignored in custom levels, because custom levels may want to use the Super Gravitron and let players have invincibility/slowdown while doing so (and there are in fact custom levels out in the wild that use the Super Gravitron; it was like one of the first things done when people discovered internal scripting). No message pops up when the game sends you back to the Secret Lab, but no message popped up when the Secret Lab menu option was disabled previously in the first place, so I haven't made anything WORSE, per se. A nice effect of this is that you can have invincibility/slowdown enabled and still be able to go to the Secret Lab from the menu. This is useful if you just want to check your trophies and leave, without having to go out of your way to disable invincibility/slowdown just to go inside.
2021-05-04 03:57:13 +02:00
return (
!map.custommode
&& swnmode
&& (swngame == 1 || swngame == 6 || swngame == 7)
)
|| intimetrial
|| nodeathmode;
Factor out Secret Lab/Time Trial/NDM conds to function They are now factored out to an inline function named incompetitive(). This is so their usage can be changed without having to change each individual one in every place. This also clarifies the intent of using these conditionals (they are for when we're in a "competitive" mode).
2021-05-04 03:22:59 +02:00
}
Factor out slowdown/invincibility conds to function This factors out the slowdown and invincibility conditionals to a function. This means less copy-pasted code, and it also conveys intent (that we don't want to allow competitive options if we have either of these cheats enabled). This function isn't implemented in the header because then we would have to include Map.h for map.invincibility, and transitive includes are evil. Although, map.invincibility ought to be on Game instead (it was only mapclass due to 2.2-and-previous argument passing), but that's a bunch of variable reshuffling that can be done later.
2021-05-04 03:29:23 +02:00
bool Game::nocompetitive(void)
{
return slowdown < 30 || map.invincibility;
}
Reference in New Issue Copy Permalink