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

7539 lines
209 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 <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
Add support for button glyph display This adds a function that converts an action (such as interacting in-game) to the corresponding button text ("ENTER", "E") or button glyph (PlayStation triangle, Steam Deck Y, etc). This function currently only gives the existing ENTERs or Es, because I don't know how best to detect controller usage, or whether the game is running on a Steam Deck, or what buttons need to be displayed there. Still, it should now be really easy to adapt the rendering of keyboard keys to consoles, controllers, or rebound keys. To identify the actions that currently need to be displayed, this commit also adds the initial enums for action sets as described by Ethan in a comment in #834 (Jan 18, 2022).
2023-03-18 22:30:16 +01:00
#include "ButtonGlyphs.h"
Replace hardcoded temp buffer sizes with a named constant Constants.h will house constants like the screen size and others. But basically only the screen size for now. Now we don't have to type that "4 bytes per 40 chars (whole screen)" comment everywhere...
2021-09-13 06:39:07 +02:00
#include "Constants.h"
Rename editor.h to CustomLevels.h This accompanies the editor.cpp -> CustomLevels.cpp change; I'll be splitting out the editor functions in the next commit. The name of the include guard has been changed as well, but not anything else.
2021-02-20 08:19:09 +01:00
#include "CustomLevels.h"
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"
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
#include "Editor.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 "Entity.h"
#include "Enums.h"
#include "FileSystemUtils.h"
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
#include "Font.h"
Split glitchrunner mode into multiple versions Previously, turning glitchrunner mode on essentially locked you to emulating 2.0, and turning it off just meant normal 2.3 behavior. But what if you wanted 2.2 behavior instead? Well, that's what I had to ask when a TAS of mine would desync in 2.3 because of the two-frame delay fix (glitchrunner off), but would also desync because of 2.0 warp lines (glitchrunner on). What I've done is made it so there are three states to glitchrunner mode now: 2.0 (previously just the "on" state), 2.2 (previously a state you couldn't use), and "off". Furthermore, I made it an enum, so in case future versions of the game patch out more glitches, we can add them to the enum (and the only other thing we have to update is a lookup table in GlitchrunnerMode.c). Also, 2.2 glitches exist in 2.0, so you'll want to use GlitchrunnerMode_less_than_or_equal() to check glitchrunner version.
2021-08-05 02:09:49 +02:00
#include "GlitchrunnerMode.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 "Graphics.h"
Add level debugger screen The level debugger is toggleable in playtesting mode by pressing Y. You can toggle whether or not the game is paused inside of the debugger by pressing TAB. The debugger screen allows you to see entity and block properties, and allows you to move them around.
2023-07-02 04:02:25 +02:00
#include "LevelDebugger.h"
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
#include "Localization.h"
#include "LocalizationStorage.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"
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
#include "RoomnameTranslator.h"
Extern `gameScreen`, remove `screenbuffer` I know earlier I removed the gameScreen extern in favor of using screenbuffer, but that was only to be consistent. After further consideration, I have found that it's actually really stupid. There's no reason to be accessing it through screenbuffer, and it's probably an artifact of 2.0-2.2 passing stack-allocated otherwise-global classes everywhere through function arguments. Also, it leads to stupid bugs where screenbuffer could potentially be NULL, which has already resulted in various annoying crashes in the past. Although those could be fixed by simply initializing screenbuffer at the very top of main(), but, why not just scrap the whole thing anyway? So that's what I'm doing. As a nice side effect, I've removed the transitive include of Screen.h from Graphics.h. This could've been done already since it only includes it for the pointer anyway, but it's still good to do it now.
2021-12-25 08:56:47 +01:00
#include "Screen.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "Script.h"
Silence various warnings in builds removing content The MAKEANDPLAY, NO_CUSTOM_LEVELS, and NO_EDITOR defines remove content or features. However, they then raise several warnings because of some cases, functions, or variables that end up not being used. This silences them by using the UNUSED macro, or by adding a default catch-all case if the define is defined (so unhandled cases will still raise warnings in a build that doesn't have these defines).
2023-02-04 09:14:04 +01:00
#include "Unused.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 "UtilityClass.h"
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
#include "VFormat.h"
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
#include "Vlogging.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
}
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
// Unfortunate forward-declare... My hands are pretty tied
static void loadthissummary(
const char* filename,
struct Game::Summary* summary,
tinyxml2::XMLDocument& doc
);
static struct Game::Summary get_summary(
De-duplicate quick/telesummary fetching in Game::init() The less copy-pasted code, the less work for me later.
2021-03-23 22:42:33 +01:00
const char* filename,
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
const char* savename,
De-duplicate quick/telesummary fetching in Game::init() The less copy-pasted code, the less work for me later.
2021-03-23 22:42:33 +01:00
tinyxml2::XMLDocument& doc
) {
tinyxml2::XMLHandle hDoc(&doc);
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
struct Game::Summary summary;
SDL_zero(summary);
De-duplicate quick/telesummary fetching in Game::init() The less copy-pasted code, the less work for me later.
2021-03-23 22:42:33 +01:00
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
if (!FILESYSTEM_loadTiXml2Document(filename, doc))
De-duplicate quick/telesummary fetching in Game::init() The less copy-pasted code, the less work for me later.
2021-03-23 22:42:33 +01:00
{
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
vlog_info("%s not found", savename);
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
return summary;
De-duplicate quick/telesummary fetching in Game::init() The less copy-pasted code, the less work for me later.
2021-03-23 22:42:33 +01:00
}
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
loadthissummary(savename, &summary, doc);
De-duplicate quick/telesummary fetching in Game::init() The less copy-pasted code, the less work for me later.
2021-03-23 22:42:33 +01:00
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
return summary;
De-duplicate quick/telesummary fetching in Game::init() The less copy-pasted code, the less work for me later.
2021-03-23 22:42:33 +01:00
}
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
{
Add magic string to the start of the `game` global The `-addresses` command-line option added in 64be99d4 helps autosplitters on platforms where VVVVVV is not built as a position-independent executable. macOS has made it increasingly difficult, or impossible, to build binaries without PIE. Adding an obvious string to search for will help tools that need to deal with versions of VVVVVV built with PIE. The bytestring to search for is `[vVvVvV]game`, followed by four null bytes (to avoid finding it in the program code section). This identifies the beginning of the game object; addresses to other objects can be figured out by relative offsets printed by `-addresses`, since ASLR can only change where the globals begin. Partially fixes #928; it may still be advisable to figure out how to explicitly disable PIE on Windows/Linux.
2023-02-21 21:09:43 +01:00
SDL_strlcpy(magic, "[vVvVvV]game", sizeof(magic));
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;
Rename `respawncolour` to `savecolour` Since it's a variable like saverx/savery/savex/savey, it should be renamed to savecolour and placed with all of them.
2021-09-07 03:28:28 +02:00
savecolour = 0;
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
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;
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;
Add `setactivityposition(x,y)`, add new textbox color `transparent` (#847) * Add `setactivityposition(x,y)`, add new textbox color `transparent` This commit adds a new internal command as a part of the visual activity zone changes I've been making. This one allows the user to reposition the activity zone to anywhere on the screen. In addition, this commit adds the textbox color `transparent`, which just sets r, g and b to 0. rgb(0, 0, 0) normally creates the color black, however in VVVVVV textboxes, it makes the background of them invisible, and makes the text the off-white color which the game uses elsewhere. * add new variables to hardreset * Fix unwanted text centering; offset position by 16, 4 It makes sense for `setactivityposition(0, 0)` to place the activity zone in the default position, so the x has been offset by 16, and the y has been offset by 4. Text was being automatically centered, meaning any activity zone which wasn't centered had misplaced text. This has been fixed by calculating the center manually, and offsetting it by the passed value.
2021-10-14 00:38:51 +02:00
activity_y = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 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;
//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;
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
menutestmode = false;
Use dynamic credits lists for main menu credits screens (and add GitHub contributors) (#160) Also added GitHub contributors to the credits on the main menu (previously they were only present in the credits at the end of the game)
2020-02-12 05:45:58 +01:00
current_credits_list_index = 0;
Add localisation credits to main menu credits In addition, this adds Ally and mothbeanie to the Localisation Implementation page credits. Also updated the game complete credits!
2023-12-06 00:34:05 +01:00
translator_credits_pagenum = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuxoff = 0;
menuyoff = 0;
menucountdown = 0;
levelpage=0;
playcustomlevel=0;
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;
Seed with frame counter instead of `SDL_GetTicks` Using SDL_GetTicks() to seed the Gravitron RNG caused many reproducibility issues while syncing https://tasvideos.org/7575S . To fix this, add a frame counter, which is a number that is incremented every frame and never resets, and use it instead. If someone needs to switch back to SDL_GetTicks() for old TASes, then provide the -seed-use-sdl-getticks command-line option for them.
2022-11-14 23:10:24 +01:00
framecounter = 0;
seed_use_sdl_getticks = false;
Remove NO_EDITOR/NO_CUSTOM_LEVELS, disable editor on Steam Deck This commit removes the `NO_EDITOR` and `NO_CUSTOM_LEVELS` defines, which cleans up the code a lot, and they weren't really needed anyways. This commit also disables the editor on the Steam Deck, and adds a program argument to re-enable the editor, `-enable-editor`.
2023-08-23 19:51:11 +02:00
editor_disabled = false;
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";
savetrinkets = 0;
intimetrial = false;
timetrialcountdown = 0;
timetrialshinytarget = 0;
timetrialparlost = false;
timetrialpar = 0;
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
timetrialcheater = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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;
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
start_translator_exploring = false;
translator_exploring = false;
translator_exploring_allowtele = false;
Add cutscene test menu This allows translators to test all text boxes in the scripts. It doesn't run the scripts themselves - it only shows the basic appearance of each text box individually, so context may be lost but it's good to have a way to see any text boxes that might otherwise not be easily seen because they require specific circumstances to appear.
2022-12-24 04:16:56 +01:00
translator_cutscene_test = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
totalflips = 0;
hardestroom = "Welcome Aboard";
hardestroomdeaths = 0;
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
hardestroom_x = 13;
hardestroom_y = 5;
hardestroom_specialname = false;
hardestroom_finalstretch = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
currentroomdeaths=0;
inertia = 1.1f;
swnmode = false;
swntimer = 0;
Use enums for swngame This replaces the swngame int variable with a named enum and enforces strict typechecking on it. Strict typechecking is okay here as the swngame variable is not part of the API surface of the game in any way and is completely internal. And just to make things clear, I've added a SWN_NONE enum to use for initialization, because previously it was being initialized to 0, even though 0 was the Gravitron.
2023-06-05 08:24:31 +02:00
swngame = SWN_NONE; // Not playing sine wave ninja!
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
swnstate = 0;
swnstate2 = 0;
swnstate3 = 0;
swnstate4 = 0;
swndelay = 0;
swndeaths = 0;
supercrewmate = false;
scmhurt = false;
scmprogress = 0;
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;
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
last_quicksave = get_summary("saves/qsave.vvv", "qsave.vvv", doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Convert Game::Game() to TinyXML2
2020-06-04 04:29:44 +02:00
tinyxml2::XMLDocument docTele;
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
last_telesave = get_summary("saves/tsave.vvv", "tsave.vvv", doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
screenshake = flashlight = 0 ;
stat_trinkets = 0;
state = 1;
Update desktop_version/src/Game.cpp Co-authored-by: Misa Elizabeth Kai <infoteddy@infoteddy.info>
2022-12-08 02:34:11 +01:00
statedelay = 0;
state locking
2022-12-07 00:20:48 +01:00
statelocked = 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
//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 in-game timer option (#790)
2021-08-05 23:31:20 +02:00
showingametimer = 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
ingame_editormode = false;
Remove NO_EDITOR/NO_CUSTOM_LEVELS, disable editor on Steam Deck This commit removes the `NO_EDITOR` and `NO_CUSTOM_LEVELS` defines, which cleans up the code a lot, and they weren't really needed anyways. This commit also disables the editor on the Steam Deck, and adds a program argument to re-enable the editor, `-enable-editor`.
2023-08-23 19:51:11 +02:00
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 unfocus audio pause option Some people prefer the 2.2 behavior where unfocusing pauses the game, but the music still plays. One such person is Trinket9 on the VVVVVV Discord server, who wanted it that way. The reason audio pausing was added in the first place was to prevent desyncing music in levels with cutscenes that synced to music. Rather than reverting it, let's add this option instead.
2021-08-05 21:20:05 +02:00
disableaudiopause = false;
Add audiopause(on/off) command If you have unfocus pause off, and unfocus audio pause off, then this command will go into effect. When it's set to on, the audio will pause when you unfocus the game. When it's set to off, the audio will not. This is different from the setting, and gets saved to the save file.
2021-08-12 03:08:32 +02:00
disabletemporaryaudiopause = true;
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;
Fix regression with controller binds on first launch I noticed that in 2.3, the game would launch with default controller binds upon first launch (e.g. no pre-existing unlock.vvv or settings.vvv), but in 2.4, this wasn't the case, and the default binds would only be set the next time the game was launched. This would result in you being essentially unable to use the controller on first launch save for the analogue stick and D-pad to move between menu selections and move the player. Bisecting pointed to commit 3ef5248db93541f399e8220fe0280281881d8bd6 as the cause of the regression. It turns out returning early upon error or a file not existing didn't set the default controller binds, because they were done at the end of Game::deserializesettings(). But the binds would be set on the next launch because if the file didn't exist, a new file would be written, not with the default binds, but then the next launch would read the file, see there were no binds, and then set the default binds accordingly. To fix this, I made it so that the default controller binds are set when Game is initialized. That way, it covers all cases where the game can't read a settings file.
2023-04-15 20:14:35 +02:00
Show skip prompt during credits and ending picture This adds a "- Press {button} to skip -" prompt to both the credits and ending picture sequences. It was always possible to skip them by pressing Enter, but not many people knew this. In fact, even I didn't know this until I saw Elomavi do it a year or so ago. So it's not really intuitive that this is possible. The prompt only shows up if you've completed the game before, and disappears after two seconds similar to the "[Press {button} to return to editor]" text. Unfortunately, given how the game works, game completion is detected based on if you have unlocked Flip Mode or not. At this point, the unlock for the game being completed (unlock 5) will already be set to true no matter what during the Plenary fanfare, but the Flip Mode unlock (unlock 18) won't be until the player hits "play" on the main menu. As a special case, the prompt will always show up in M&P (because Flip Mode is always unlocked in M&P).
2023-05-22 21:18:40 +02:00
old_skip_message_timer = 0;
skip_message_timer = 0;
Fix regression with controller binds on first launch I noticed that in 2.3, the game would launch with default controller binds upon first launch (e.g. no pre-existing unlock.vvv or settings.vvv), but in 2.4, this wasn't the case, and the default binds would only be set the next time the game was launched. This would result in you being essentially unable to use the controller on first launch save for the analogue stick and D-pad to move between menu selections and move the player. Bisecting pointed to commit 3ef5248db93541f399e8220fe0280281881d8bd6 as the cause of the regression. It turns out returning early upon error or a file not existing didn't set the default controller binds, because they were done at the end of Game::deserializesettings(). But the binds would be set on the next launch because if the file didn't exist, a new file would be written, not with the default binds, but then the next launch would read the file, see there were no binds, and then set the default binds accordingly. To fix this, I made it so that the default controller binds are set when Game is initialized. That way, it covers all cases where the game can't read a settings file.
2023-04-15 20:14:35 +02:00
setdefaultcontrollerbuttons();
}
void Game::setdefaultcontrollerbuttons(void)
{
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);
}
if (controllerButton_restart.size() < 1)
{
controllerButton_restart.push_back(SDL_CONTROLLER_BUTTON_RIGHTSHOULDER);
}
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
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--;
Disable more flashing elements if a11y is on For some reason, the accessibility option that was meant to disable flashes doesn't disable ALL flashes, only screen flashes and screen shaking. This commit disables a lot more, most importantly randomness in colors, the player flashing on death/respawn, and teleporters flashing.
2023-04-06 01:45:40 +02:00
if (INBOUNDS_VEC(i, obj.entities) && (lifeseq <= 0 || noflashingmode))
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)
{
Prevent other cases of losing unsaved levels by returning to menu 2.3 already made it so that if you ran the `rollcredits` command during in-editor playtesting, you wouldn't be returned to the title screen while losing unsaved level changes. But there are plenty of other ways to go back to the title screen from in-editor playtesting too. Namely, gamestate 1015 (the gamestate after completing a level) and 82 (time trial complete). So just add the appropriate checks to those gamestates, and add a catch-all check in Game::quittomenu(). Additionally, Game::updatecustomlevelstats() should not update custom level stats during in-editor playtesting (otherwise it would still happen even if the game didn't bring you back to the title screen). Editor notes will also be shown if the game prevents you from going to the title screen. Also, just to make things clear, I also added a level note for when the level is completed during in-editor playtesting. This is just to make it clear in cases where it might not be obvious that the game returned you to the editor for this reason. E.g. you have a terminal that calls gamestate(1013) in a level with 0 custom crewmates, but when you activate it, it looks like the terminal didn't work for some reason and just brought you back to the editor. But that's just only because you literally just completed the level.
2023-05-19 04:58:23 +02:00
if (!map.custommodeforreal)
{
/* We are playtesting, don't update level stats */
return;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (clevel.find("levels/") != std::string::npos)
{
clevel = clevel.substr(7);
}
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
if (customlevelstats.count(clevel) == 0 || cscore > customlevelstats[clevel])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
customlevelstats[clevel] = cscore;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
savecustomlevelstats();
}
Add option to delete all custom level save data To match the option to nuke all main game save data, there is also now an option to nuke all custom level save data separately (which is just all custom level quicksaves, along with stars for level completion). It has its own confirmation menu too. It does not delete any levels from the levels folder.
2021-08-12 05:54:02 +02:00
void Game::deletecustomlevelstats(void)
{
customlevelstats.clear();
if (!FILESYSTEM_delete("saves/levelstats.vvv"))
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Error deleting levelstats.vvv");
Add option to delete all custom level save data To match the option to nuke all main game save data, there is also now an option to nuke all custom level save data separately (which is just all custom level quicksaves, along with stars for level completion). It has its own confirmation menu too. It does not delete any levels from the levels folder.
2021-08-12 05:54:02 +02: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_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;
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
tinyxml2::XMLHandle hDoc(&doc);
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
if (!FILESYSTEM_loadTiXml2Document("saves/levelstats.vvv", doc))
{
//No levelstats file exists; start new
customlevelstats.clear();
savecustomlevelstats();
return;
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
if (doc.Error())
{
vlog_error("Error parsing levelstats.vvv: %s", doc.ErrorStr());
return;
}
Clear level stats vector before loading them into the vector Otherwise this results in what is basically a memory leak that can be triggered repeatedly by selecting "play a level" over and over again. Fixes #885.
2022-08-04 02:21:35 +02:00
customlevelstats.clear();
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
tinyxml2::XMLElement* pElem;
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
tinyxml2::XMLElement* firstElement;
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
firstElement = hDoc
.FirstChildElement()
.FirstChildElement("Data")
.FirstChildElement()
.ToElement();
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
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
for (pElem = firstElement; pElem != NULL; pElem = pElem->NextSiblingElement())
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +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
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
{
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
bool file_has_duplicates = false;
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
{
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
int score = 0;
std::string 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
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
{
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
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
{
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
name = stat_el->Attribute("name");
}
int existing = customlevelstats.count(name);
if (existing > 0)
{
file_has_duplicates = true;
}
if (existing == 0 || score > customlevelstats[name])
{
customlevelstats[name] = score;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
if (file_has_duplicates)
{
/* This might be really inflated, so simply save the map we have now,
* so we don't have to keep loading a 90 MB file. */
savecustomlevelstats();
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
Game::loadcustomlevelstats: move some declarations to later in function The declarations of `std::vector<std::string> customlevelnames` and `std::vector<int> customlevelscores` are made quite early in the function, commented with "Old system", but the place where the old system is processed is after a big chunk of code that processes the new system (and indeed never uses these vectors). So for readability, they're now closer to where they're used.
2023-10-25 02:57:50 +02:00
std::vector<std::string> customlevelnames;
std::vector<int> customlevelscores;
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
for (pElem = firstElement; pElem; pElem=pElem->NextSiblingElement())
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +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
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
Remove `VVV_min/max` in favor of `SDL_min/max` VVV_min/max are functions that only operate on ints, and SDL_min/max are macros that operate on any type but double-evaluate everything. I know I more-or-less said earlier that SDL_min/max were dumb but I've changed my mind and think it's better to use them, taking care to make sure you don't double-evaluate, rather than trying to generate your own litany of functions with either your own hand-rolled generation macros, C++ templates, C11 generics, or GCC extensions (that last one you'd technically use in a macro but it doesn't really matter), all of which have more downsides than just not double-evaluating. And the upside of not double-evaluating is that you're disencouraged from having really complicated single-line min/max expressions and encouraged to precompute the values beforehand anyway so the final min/max is more readable. And furthermore you'll notice when you yourself end up doing double-evaluations anyway. I removed a couple instances of Graphics::len() being double-evaluated in this commit (as well as cleaned up some other min/max-using code). Although the only downside to those double-evaluations was unnecessary computation, rather than checking the wrong result or having multiple side effects, thankfully, it's still good to minimize double-evaluations where possible.
2021-12-23 01:43:31 +01:00
for (size_t i = 0; i < SDL_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
{
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
const std::string& name = customlevelnames[i];
const int score = customlevelscores[i];
if (customlevelstats.count(name) == 0 || score > customlevelstats[name])
{
customlevelstats[name] = score;
}
Unindent loadcustomlevelstats from previous commit Done in a separate commit to reduce diff noise.
2020-06-30 03:47:45 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void 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)
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("No levelstats.vvv found. Creating new file");
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
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
else if (doc.Error())
{
vlog_error("Error parsing existing levelstats.vvv: %s", doc.ErrorStr());
vlog_info("Creating new levelstats.vvv");
}
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_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;
std::string customlevelstatsstr;
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
std::map<std::string, int>::iterator iter;
for (iter = customlevelstats.begin(); iter != customlevelstats.end(); iter++)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
customlevelscorestr += help.String(iter->second) + ",";
customlevelstatsstr += iter->first + "|";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
xml::update_tag(msgs, "customlevelscore", customlevelscorestr.c_str());
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;
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
for (iter = customlevelstats.begin(); iter != customlevelstats.end(); iter++)
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
{
stat_el = doc.NewElement("stat");
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
stat_el->SetAttribute("name", iter->first.c_str());
stat_el->LinkEndChild(doc.NewText(help.String(iter->second).c_str()));
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
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
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("Level stats saved");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Could Not Save level stats!");
vlog_error("Failed: %s%s", 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)
{
Add `textimage` for `levelcomplete` and `gamecomplete` `levelcomplete` and `gamecomplete` were hardcoded using textbox colors which were offset by 1. This PR fixes that, no longer requiring slightly-off colors, and instead adding a new property to textboxes which tell the game to display either level complete or game complete.
2023-08-20 19:11:44 +02:00
graphics.createtextboxflipme("", -1, 12, TEXT_COLOUR("cyan"));
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
graphics.addline(" ");
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("");
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
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();
Add `textimage` for `levelcomplete` and `gamecomplete` `levelcomplete` and `gamecomplete` were hardcoded using textbox colors which were offset by 1. This PR fixes that, no longer requiring slightly-off colors, and instead adding a new property to textboxes which tell the game to display either level complete or game complete.
2023-08-20 19:11:44 +02:00
graphics.setimage(TEXTIMAGE_LEVELCOMPLETE);
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
}
Finish implementing sprites in textboxes This commit adjusts the Y position for flip-mode, and makes the main game use this new system.
2023-08-11 02:41:39 +02:00
void Game::crewmate_textbox(const int color)
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
{
Fix various CJK positioning problems - ERROR/WARNING screen title was overlapping with message - Crewmate screen names and rescued statuses were overlapping with each other - Textboxes on Level Complete screen were overlapping with each other and the crewmate was not vertically centered in the box - Some strings were running into each other in flip mode, instead of being moved out of each other (PR_CJK_HIGH and PR_CJK_LOW worked the wrong way around because of FLIP macros being applied to Y coords) - In-game esc menu was "bouncy" with selected menu options because of a hardcoded 16 pixel offset - Bindings in the gamepad menu were overlapping with each other - Some Super Gravitron "Best Time" labels and values were a little too close
2023-07-12 22:58:47 +02:00
const int extra_cjk_height = (font::height(PR_FONT_INTERFACE) * 4) - 32;
Finish implementing sprites in textboxes This commit adjusts the Y position for flip-mode, and makes the main game use this new system.
2023-08-11 02:41:39 +02:00
graphics.createtextboxflipme("", -1, 64 + 8 + 16 - extra_cjk_height/2, TEXT_COLOUR("gray"));
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
/* This is a special case for wrapping, we MUST have two lines.
* So just make sure it can't fit in one line. */
const char* text = loc::gettext("You have rescued a crew member!");
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
std::string wrapped = font::string_wordwrap_balanced(PR_FONT_INTERFACE, text, font::len(PR_FONT_INTERFACE, text)-1);
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
size_t startline = 0;
size_t newline;
do {
size_t pos_n = wrapped.find('\n', startline);
size_t pos_p = wrapped.find('|', startline);
newline = SDL_min(pos_n, pos_p);
graphics.addline(wrapped.substr(startline, newline-startline));
startline = newline+1;
} while (newline != std::string::npos);
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("");
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
graphics.textboxcentertext();
Fix various CJK positioning problems - ERROR/WARNING screen title was overlapping with message - Crewmate screen names and rescued statuses were overlapping with each other - Textboxes on Level Complete screen were overlapping with each other and the crewmate was not vertically centered in the box - Some strings were running into each other in flip mode, instead of being moved out of each other (PR_CJK_HIGH and PR_CJK_LOW worked the wrong way around because of FLIP macros being applied to Y coords) - In-game esc menu was "bouncy" with selected menu options because of a hardcoded 16 pixel offset - Bindings in the gamepad menu were overlapping with each other - Some Super Gravitron "Best Time" labels and values were a little too close
2023-07-12 22:58:47 +02:00
float spaces_per_8 = font::len(PR_FONT_INTERFACE, " ")/8.0f;
graphics.textboxpad(SDL_ceilf(5/spaces_per_8), SDL_ceilf(2/spaces_per_8));
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();
Fix position of crewmate in "You have rescued a crew member!" box At first my CJK changes also misaligned this sprite, and my solution that time was to position the textbox higher depending on the height of the textbox, so it would be centered around the crewmate sprite (which stayed at a hardcoded place onscreen). Recently, #987 changed these sprites to be relative to the position of the textbox instead of relative to the screen, which is much more logical, but it stopped centering these sprites again. But it's an easy fix: simply account for the extra-added height when adding the sprite in.
2023-11-27 23:25:18 +01:00
graphics.addsprite(14, 12 + extra_cjk_height/2, 0, color);
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::remaining_textbox(void)
{
const int remaining = 6 - crewrescued();
Replace hardcoded temp buffer sizes with a named constant Constants.h will house constants like the screen size and others. But basically only the screen size for now. Now we don't have to type that "4 bytes per 40 chars (whole screen)" comment everywhere...
2021-09-13 06:39:07 +02:00
char buffer[SCREEN_WIDTH_CHARS + 1];
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
if (remaining > 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
{
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
loc::gettext_plural_fill(buffer, sizeof(buffer), "{n_crew|wordy} remain", "{n_crew|wordy} remains", "n_crew:int", remaining);
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
}
else
{
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
SDL_strlcpy(buffer, loc::gettext("All Crew Members Rescued!"), sizeof(buffer));
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
}
Fix various CJK positioning problems - ERROR/WARNING screen title was overlapping with message - Crewmate screen names and rescued statuses were overlapping with each other - Textboxes on Level Complete screen were overlapping with each other and the crewmate was not vertically centered in the box - Some strings were running into each other in flip mode, instead of being moved out of each other (PR_CJK_HIGH and PR_CJK_LOW worked the wrong way around because of FLIP macros being applied to Y coords) - In-game esc menu was "bouncy" with selected menu options because of a hardcoded 16 pixel offset - Bindings in the gamepad menu were overlapping with each other - Some Super Gravitron "Best Time" labels and values were a little too close
2023-07-12 22:58:47 +02:00
// In CJK, the "You have rescued" box becomes so big we should lower this one a bit...
const int cjk_lowering = font::height(PR_FONT_INTERFACE) - 8;
graphics.createtextboxflipme(buffer, -1, 128 + 16 + cjk_lowering, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
graphics.textboxpad(2, 2);
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)
{
Replace ACTION in texts by {button} placeholders Gamepads and the Steam Deck need "ACTION" to be replaced by a controller glyph, so that's now possible.
2023-03-18 22:32:26 +01:00
char buffer[SCREEN_WIDTH_CHARS + 1];
vformat_buf(
buffer, sizeof(buffer),
loc::gettext("Press {button} to continue"),
"button:but",
vformat_button(ActionSet_InGame, Action_InGame_ACTION)
);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(buffer, -1, 196, TEXT_COLOUR("cyan"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
graphics.textboxpad(1, 1);
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())
{
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(loc::gettext("Game Saved"), -1, 12, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
graphics.textboxpad(3, 3);
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
graphics.textboxtimer(25);
}
else
{
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(loc::gettext("ERROR: Could not save game!"), -1, 12, TEXT_COLOUR("red"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: make remaining strings translatable except gethardestroom This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:38:05 +01:00
graphics.textboxwrap(2);
graphics.textboxpad(1, 1);
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
graphics.textboxtimer(50);
}
}
Apply suggestions from code review Co-authored-by: Misa Elizabeth Kai <infoteddy@infoteddy.info>
2022-12-07 18:32:28 +01:00
void Game::setstate(const int gamestate)
state locking
2022-12-07 00:20:48 +01:00
{
if (!statelocked)
{
state = gamestate;
}
}
Style: Fixup instances of `void` arguments The style we have here is that functions with no arguments are to have explicit `void` arguments, even though this doesn't apply in C++, because it does apply in C. Unfortunately, some have slipped through the cracks. This commit fixes them.
2023-03-18 23:24:14 +01:00
void Game::incstate(void)
state locking
2022-12-07 00:20:48 +01:00
{
if (!statelocked)
{
state++;
}
}
Apply suggestions from code review Co-authored-by: Misa Elizabeth Kai <infoteddy@infoteddy.info>
2022-12-07 18:32:28 +01:00
void Game::setstatedelay(const int delay)
Also lock statedelay
2022-12-07 00:35:06 +01:00
{
if (!statelocked)
{
statedelay = delay;
}
}
Style: Fixup instances of `void` arguments The style we have here is that functions with no arguments are to have explicit `void` arguments, even though this doesn't apply in C++, because it does apply in C. Unfortunately, some have slipped through the cracks. This commit fixes them.
2023-03-18 23:24:14 +01:00
void Game::lockstate(void)
state locking
2022-12-07 00:20:48 +01:00
{
statelocked = true;
}
Style: Fixup instances of `void` arguments The style we have here is that functions with no arguments are to have explicit `void` arguments, even though this doesn't apply in C++, because it does apply in C. Unfortunately, some have slipped through the cracks. This commit fixes them.
2023-03-18 23:24:14 +01:00
void Game::unlockstate(void)
state locking
2022-12-07 00:20:48 +01:00
{
statelocked = 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::updatestate(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
statedelay--;
Apply suggestions from code review Co-authored-by: Misa Elizabeth Kai <infoteddy@infoteddy.info>
2022-12-07 18:32:28 +01:00
if (statedelay <= 0)
{
Also lock statedelay
2022-12-07 00:35:06 +01:00
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
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
{
Remove dialogue and cutscene bars if disabling completestop This fixes a bug where the trinket collection text boxes, along with the cutscene bars, would stay on-screen if the player warped to the ship while they were up. This only happens during the gamestate 0 anti-softlock checks, and only if completestop is active in the first place, so text boxes aren't cleared if the player is doing something that wouldn't lead to a softlock otherise. Fixes #921.
2023-03-19 21:48:01 +01:00
if (completestop)
{
/* Close potential collection dialogue if warping to ship */
graphics.textboxremove();
graphics.showcutscenebars = false;
}
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
/* 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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 2:
//Opening cutscene
advancetext = true;
hascontrol = false;
state locking
2022-12-07 00:20:48 +01:00
setstate(3);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("To do: write quick", 50, 80, TEXT_COLOUR("cyan"));
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("intro to story!");
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
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
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(BUTTONGLYPHS_get_wasd_text(), -1, 195, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxwrap(4);
graphics.textboxcentertext();
graphics.textboxpad(2, 2);
graphics.textboxcenterx();
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(60);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 5:
//Demo over
advancetext = true;
hascontrol = false;
startscript = true;
newscript="returntohub";
obj.removetrigger(5);
state locking
2022-12-07 00:20:48 +01:00
setstate(6);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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;
Add support for button glyph display This adds a function that converts an action (such as interacting in-game) to the corresponding button text ("ENTER", "E") or button glyph (PlayStation triangle, Steam Deck Y, etc). This function currently only gives the existing ENTERs or Es, because I don't know how best to detect controller usage, or whether the game is running on a Steam Deck, or what buttons need to be displayed there. Still, it should now be really easy to adapt the rendering of keyboard keys to consoles, controllers, or rebound keys. To identify the actions that currently need to be displayed, this commit also adds the initial enums for action sets as described by Ethan in a comment in #834 (Jan 18, 2022).
2023-03-18 22:30:16 +01:00
char buffer[SCREEN_WIDTH_CHARS*3 + 1];
vformat_buf(
buffer, sizeof(buffer),
loc::gettext("Press {button} to view map and quicksave"),
"button:but",
vformat_button(ActionSet_InGame, Action_InGame_Map)
);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(buffer, -1, 155, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxwrap(4);
graphics.textboxcentertext();
graphics.textboxpad(2, 2);
graphics.textboxcenterx();
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(60);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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();
Add message when player is kicked out of Super Gravitron The player gets kicked out of the Super Gravitron if they have invincibility or slowdown enabled. However, this can be confusing if no message pops up ( https://steamcommunity.com/app/70300/discussions/0/3039355280230178910/ ) . So I've made it so that a text box will pop up when they get kicked out.
2021-09-03 21:08:31 +02:00
startscript = true;
newscript = "disableaccessibility";
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
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
break;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Start SWN Minigame Mode B
obj.removetrigger(9);
swnmode = true;
Use enums for swngame This replaces the swngame int variable with a named enum and enforces strict typechecking on it. Strict typechecking is okay here as the swngame variable is not part of the API surface of the game in any way and is completely internal. And just to make things clear, I've added a SWN_NONE enum to use for initialization, because previously it was being initialized to 0, even though 0 was the Gravitron.
2023-06-05 08:24:31 +02:00
swngame = SWN_START_SUPERGRAVITRON_STEP_1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 10:
//Start SWN Minigame Mode A
obj.removetrigger(10);
swnmode = true;
Use enums for swngame This replaces the swngame int variable with a named enum and enforces strict typechecking on it. Strict typechecking is okay here as the swngame variable is not part of the API surface of the game in any way and is completely internal. And just to make things clear, I've added a SWN_NONE enum to use for initialization, because previously it was being initialized to 0, even though 0 was the Gravitron.
2023-06-05 08:24:31 +02:00
swngame = SWN_START_GRAVITRON_STEP_1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 11:
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//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();
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
const char* floorceiling = graphics.flipmode ? "ceiling" : "floor";
const char* crewmate;
switch (lastsaved)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
case 2:
crewmate = "Vitellary";
break;
case 3:
crewmate = "Vermilion";
break;
case 4:
crewmate = "Verdigris";
break;
case 5:
crewmate = "Victoria";
break;
default:
crewmate = "your companion";
}
char english[SCREEN_WIDTH_TILES*3 + 1]; /* ASCII only */
vformat_buf(english, sizeof(english),
"When you're NOT standing on the {floorceiling}, {crewmate} will stop and wait for you.",
"floorceiling:str, crewmate:str",
floorceiling, crewmate
);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext(english), -1, 3, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxwrap(2);
graphics.textboxpadtowidth(36*8);
graphics.textboxcenterx();
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(180);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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();
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
const char* english;
switch (lastsaved)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
case 2:
case 3:
case 4:
english = "You can't continue to the next room until he is safely across.";
break;
case 5:
english = "You can't continue to the next room until she is safely across.";
break;
default:
english = "You can't continue to the next room until they are safely across.";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext(english), -1, 3, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxwrap(2);
graphics.textboxpadtowidth(36*8);
graphics.textboxcenterx();
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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();
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 14:
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Intermission 1 instructional textbox, depends on last saved
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
const char* floorceiling = graphics.flipmode ? "ceiling" : "floor";
const char* crewmate;
switch (lastsaved)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
case 2:
crewmate = "Vitellary";
break;
case 3:
crewmate = "Vermilion";
break;
case 4:
crewmate = "Verdigris";
break;
case 5:
crewmate = "Victoria";
break;
default:
crewmate = "your companion";
}
char english[SCREEN_WIDTH_TILES*3 + 1]; /* ASCII only */
vformat_buf(english, sizeof(english),
"When you're standing on the {floorceiling}, {crewmate} will try to walk to you.",
"floorceiling:str, crewmate:str",
floorceiling, crewmate
);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext(english), -1, 3, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxwrap(2);
graphics.textboxpadtowidth(36*8);
graphics.textboxcenterx();
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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;
}
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_CRY);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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);
Add support for button glyph display This adds a function that converts an action (such as interacting in-game) to the corresponding button text ("ENTER", "E") or button glyph (PlayStation triangle, Steam Deck Y, etc). This function currently only gives the existing ENTERs or Es, because I don't know how best to detect controller usage, or whether the game is running on a Steam Deck, or what buttons need to be displayed there. Still, it should now be really easy to adapt the rendering of keyboard keys to consoles, controllers, or rebound keys. To identify the actions that currently need to be displayed, this commit also adds the initial enums for action sets as described by Ethan in a comment in #834 (Jan 18, 2022).
2023-03-18 22:30:16 +01:00
if (BUTTONGLYPHS_keyboard_is_active())
{
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext("If you prefer, you can press UP or DOWN instead of ACTION to flip."), -1, 187, TEXT_COLOUR("gray"));
Add support for button glyph display This adds a function that converts an action (such as interacting in-game) to the corresponding button text ("ENTER", "E") or button glyph (PlayStation triangle, Steam Deck Y, etc). This function currently only gives the existing ENTERs or Es, because I don't know how best to detect controller usage, or whether the game is running on a Steam Deck, or what buttons need to be displayed there. Still, it should now be really easy to adapt the rendering of keyboard keys to consoles, controllers, or rebound keys. To identify the actions that currently need to be displayed, this commit also adds the initial enums for action sets as described by Ethan in a comment in #834 (Jan 18, 2022).
2023-03-18 22:30:16 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
graphics.textboxwrap(2);
graphics.textboxcentertext();
graphics.textboxpad(1, 1);
graphics.textboxcenterx();
graphics.textboxtimer(100);
}
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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;
state locking
2022-12-07 00:20:48 +01:00
setstate(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;
state locking
2022-12-07 00:20:48 +01:00
setstate(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;
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Replace ACTION in texts by {button} placeholders Gamepads and the Steam Deck need "ACTION" to be replaced by a controller glyph, so that's now possible.
2023-03-18 22:32:26 +01:00
char buffer[SCREEN_WIDTH_CHARS*3 + 1];
vformat_buf(
buffer, sizeof(buffer),
loc::gettext("Press {button} to flip"),
"button:but",
vformat_button(ActionSet_InGame, Action_InGame_ACTION)
);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(buffer, -1, 25, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxwrap(4);
graphics.textboxcentertext();
graphics.textboxpad(2, 2);
graphics.textboxcenterx();
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(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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(30);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 31:
Also lock statedelay
2022-12-07 00:35:06 +01:00
//state = 55; setstatedelay(50);
remove two-argument setstate
2022-12-08 02:10:12 +01:00
setstate(0);
setstatedelay(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";
remove two-argument setstate
2022-12-08 02:10:12 +01:00
setstate(0);
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(32);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(33);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(34);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(35);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(36);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 37:
//Generic "run script"
if (companion == 0)
{
startscript = true;
newscript="int2_yellow";
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(37);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 38:
//Generic "run script"
if (companion == 0)
{
startscript = true;
newscript="int2_red";
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(38);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 39:
//Generic "run script"
if (companion == 0)
{
startscript = true;
newscript="int2_green";
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(39);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 40:
//Generic "run script"
if (companion == 0)
{
startscript = true;
newscript="int2_blue";
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(40);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(41);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(42);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(43);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(44);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(45);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(46);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(47);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(48);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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;
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.niceplay(Music_PREDESTINEDFATEREMIX);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
obj.removetrigger(49);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 50:
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIOLET);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext("Help! Can anyone hear this message?"), 5, 8, TEXT_COLOUR("purple"));
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxcommsrelay();
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(60);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(100);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 51:
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIOLET);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext("Verdigris? Are you out there? Are you ok?"), 5, 8, TEXT_COLOUR("purple"));
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxcommsrelay();
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(60);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(100);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 52:
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIOLET);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext("Please help us! We've crashed and need assistance!"), 5, 8, TEXT_COLOUR("purple"));
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxcommsrelay();
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(60);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(100);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 53:
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIOLET);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext("Hello? Anyone out there?"), 5, 8, TEXT_COLOUR("purple"));
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxcommsrelay();
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(60);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(100);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 54:
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIOLET);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext("This is Doctor Violet from the D.S.S. Souleye! Please respond!"), 5, 8, TEXT_COLOUR("purple"));
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxcommsrelay();
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(60);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(100);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 55:
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIOLET);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext("Please... Anyone..."), 5, 8, TEXT_COLOUR("purple"));
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxcommsrelay();
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(60);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(100);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 56:
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIOLET);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox(loc::gettext("Please be alright, everyone..."), 5, 8, TEXT_COLOUR("purple"));
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxcommsrelay();
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(60);
state locking
2022-12-07 00:20:48 +01:00
setstate(50);
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(100);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 80:
//Used to return to menu from the game
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
}
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();
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PRESENTINGVVVVVV); //should be after quittomenu()
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 82:
//Time Trial Complete!
obj.removetrigger(82);
Prevent other cases of losing unsaved levels by returning to menu 2.3 already made it so that if you ran the `rollcredits` command during in-editor playtesting, you wouldn't be returned to the title screen while losing unsaved level changes. But there are plenty of other ways to go back to the title screen from in-editor playtesting too. Namely, gamestate 1015 (the gamestate after completing a level) and 82 (time trial complete). So just add the appropriate checks to those gamestates, and add a catch-all check in Game::quittomenu(). Additionally, Game::updatecustomlevelstats() should not update custom level stats during in-editor playtesting (otherwise it would still happen even if the game didn't bring you back to the title screen). Editor notes will also be shown if the game prevents you from going to the title screen. Also, just to make things clear, I also added a level note for when the level is completed during in-editor playtesting. This is just to make it clear in cases where it might not be obvious that the game returned you to the editor for this reason. E.g. you have a terminal that calls gamestate(1013) in a level with 0 custom crewmates, but when you activate it, it looks like the terminal didn't work for some reason and just brought you back to the editor. But that's just only because you literally just completed the level.
2023-05-19 04:58:23 +02:00
if (map.custommode && !map.custommodeforreal)
{
returntoeditor();
ed.show_note(loc::gettext("Time trial completed"));
break;
}
Remove NO_EDITOR/NO_CUSTOM_LEVELS, disable editor on Steam Deck This commit removes the `NO_EDITOR` and `NO_CUSTOM_LEVELS` defines, which cleans up the code a lot, and they weren't really needed anyways. This commit also disables the editor on the Steam Deck, and adds a program argument to re-enable the editor, `-enable-editor`.
2023-08-23 19:51:11 +02:00
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
if (translator_exploring)
{
translator_exploring_allowtele = true;
Use setstate(n)/incstate()/setstatedelay(n) in localization changes This mirrors PR #917.
2022-12-31 16:01:11 +01:00
setstate(0);
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
break;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
if (timetrialcheater)
{
SDL_zeroa(obj.collect);
}
Simplify time formatting functions Here's my notes on all the existing functions and what kind of time formats they output: - Game::giventimestring(int hrs, int min, int sec) H:MM:SS MM:SS - Game::timestring() // uses game.hours/minutes/seconds H:MM:SS MM:SS - Game::partimestring() // uses game.timetrialpar (seconds) MM:SS - Game::resulttimestring() // uses game.timetrialresulttime (sec) + timetrialresultframes (1/30s) MM:SS.CC - Game::timetstring(int t) // t = seconds MM:SS - Game::timestringcenti(char* buffer, const size_t buffer_size) // uses game.hours/minutes/seconds/frames H:MM:SS.CC MM:SS.CC - UtilityClass::timestring(int t) // t = frames, 30 frames = 1 second S:CC M:SS:CC This is kind of a mess, and there's a lot of functions that do the same thing except using different variables. For localization, I also want translators to be able to localize all these time formats - many languages use the decimal comma instead of the decimal point (12:34,56) maybe some languages really prefer something like 1時02分11秒44瞬... Which I don't know to be correct, but it's good to be prepared for it and not restrict translators arbitrarily to only changing ":" and "." when we can start making the system better in the first place. I added a new function, UtilityClass::format_time. This is the place where all time formats come together, given the number of seconds and optionally frames. I have simplified the above-mentioned functions somewhat, but I haven't given them a complete refactor or renaming - I mainly made sure that they all use the same backend so I can make the formats consistent and properly localizable. (And before we start shoving more temporary char buffers everywhere just to get rid of the std::string's, maybe we need to think of a globally used working buffer of size SCREEN_WIDTH_CHARS+1, as a register of sorts, for when any line of text needs to be made or processed, then printed, and then goes unused. Maybe help.textrow, or something like that.) As for this commit, the available time formats are now more consistent and changed a little in some places. Leading zeroes for the first unit are now no longer included, time trial results and the Super Gravitron can now display hours when they went to 60 minutes before, and we now always use .CC instead of :CC. These are the formats: - H:MM:SS - H:MM:SS.CC - M:SS - M:SS.CC - S.CC (only used when always_minutes=false, for the Gravitrons) Here's what changes to the current functions: - Game::partimestring() is removed - it was used in two places, and could be replaced by game.timetstring(game.timetrialpar) - Game::giventimestring(h,m,s) and Game::timestring() are now wrappers for the other functions - The four remaining functions (Game::resulttimestring(), Game::timetstring(t), Game::timestringcenti(buffer, buffer_size) and UtilityClass::timestring(t)) are now wrappers for the "central function", UtilityClass::format_time. - UtilityClass::twodigits(int t) is now unused so it's also removed. - I also added int UtilityClass::hms_to_seconds(int h, int m, int s)
2021-12-25 17:13:46 +01:00
timetrialresulttime = help.hms_to_seconds(hours, minutes, seconds);
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;
Use enums for time trial indexes This adds an anonymous enum for time trial indexes (e.g. the bestrank, bestlives, etc. arrays and timetriallevel), and replaces all integer literals with them. Just like the unlock arrays, these are indexes to an array in XML save files, so the numbers matter, and therefore should not use strict typechecking.
2023-06-06 02:50:19 +02:00
if (timetrialrank >= 3)
{
switch (timetriallevel)
{
case TimeTrial_SPACESTATION1:
unlockAchievement("vvvvvvtimetrial_station1_fixed");
break;
case TimeTrial_LABORATORY:
unlockAchievement("vvvvvvtimetrial_lab_fixed");
break;
case TimeTrial_TOWER:
unlockAchievement("vvvvvvtimetrial_tower_fixed");
break;
case TimeTrial_SPACESTATION2:
unlockAchievement("vvvvvvtimetrial_station2_fixed");
break;
case TimeTrial_WARPZONE:
unlockAchievement("vvvvvvtimetrial_warp_fixed");
break;
case TimeTrial_FINALLEVEL:
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
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEOUT;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.fadeout();
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 83:
frames--;
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
}
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);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 85:
//Cutscene skip version of final level change
obj.removetrigger(85);
//Init final stretch
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_POSITIVEFORCE);
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 91:
//Generic "run script"
startscript = true;
newscript="startexpolevel_lab";
obj.removetrigger(91);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 92:
//Generic "run script"
startscript = true;
newscript="startexpolevel_warp";
obj.removetrigger(92);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 93:
//Generic "run script"
startscript = true;
newscript="startexpolevel_tower";
obj.removetrigger(93);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 94:
//Generic "run script"
startscript = true;
newscript="startexpolevel_station2";
obj.removetrigger(94);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 95:
//Generic "run script"
startscript = true;
newscript="startexpolevel_final";
obj.removetrigger(95);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 96:
//Used to return to gravitron to game
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
}
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();
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_UNFLIP);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
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);
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VERDIGRIS);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 104:
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("I'm glad you're ok!", 135, 152, TEXT_COLOUR("cyan"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIRIDIAN);
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...");
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_CRY);
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:
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("Don't worry! I have a", 125, 152, TEXT_COLOUR("cyan"));
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("teleporter key!");
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIRIDIAN);
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;
}
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("Follow me!", 185, 154, TEXT_COLOUR("cyan"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIRIDIAN);
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 115:
//
// Test script for space station, totally delete me!
//
hascontrol = false;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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!");
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
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();
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_UNFLIP);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
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;
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("Captain! You're ok!", 60-10, 90-40, TEXT_COLOUR("yellow"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VITELLARY);
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
{
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("I've found a teleporter, but", 60-20, 90 - 40, TEXT_COLOUR("yellow"));
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("I can't get it to go anywhere...");
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_CRY);
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:
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("I can help with that!", 125, 152-40, TEXT_COLOUR("cyan"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIRIDIAN);
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:
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("I have the teleporter", 130, 152-35, TEXT_COLOUR("cyan"));
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("codex for our ship!");
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIRIDIAN);
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
{
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("Yey! Let's go home!", 60-30, 90-35, TEXT_COLOUR("yellow"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VITELLARY);
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 200:
//Init final stretch
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 1001:
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Found a trinket!
advancetext = true;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(loc::gettext("Congratulations!\n\nYou have found a shiny trinket!"), 50, 85, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
int h = graphics.textboxwrap(2);
graphics.textboxcentertext();
graphics.textboxpad(1, 1);
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
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
int max_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
if(map.custommode)
{
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
max_trinkets = cl.numtrinkets();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
max_trinkets = 20;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
char buffer[SCREEN_WIDTH_CHARS + 1];
vformat_buf(
buffer, sizeof(buffer),
loc::gettext("{n_trinkets|wordy} out of {max_trinkets|wordy}"),
"n_trinkets:int, max_trinkets:int",
trinkets(), max_trinkets
);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(buffer, 50, 95+h, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxwrap(2);
graphics.textboxcentertext();
graphics.textboxpad(1, 1);
graphics.textboxcenterx();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
}
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 locking
2022-12-07 00:20:48 +01:00
incstate();
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
}
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Don't check `!muted` when fading music after completion prompt This was done in 2.2 and previous probably to fix the fact that there were multiple conflicting audio controls (the player wants to mute the audio but the game wants to fade in the audio), but is now actively harmful since 2.3, because muting the game while finishing the completion prompt means the music will never come back in, even after unmuting. I also notice that when collecting a custom crewmate, the game checks for the level's start music instead of if there's actually a current song playing right now. I don't know why this was done, because it would've been better to copy-paste the trinket collection logic here. It's entirely possible for the audio to just be muted and never come back if the level has no start music but plays a song by using a script. Anyways, leaving it alone because it's quite possible that a level might be intentionally designed around this, I can't really tell the intentions of every level creator, and it's easy to work around (either don't use custom crewmates, which every modern level basically does nowadays, or just set the start music).
2021-09-11 00:46:14 +02:00
if (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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 1011:
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
{
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(loc::gettext("Congratulations!\n\nYou have found a lost crewmate!"), 50, 85, TEXT_COLOUR("gray"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
int h = graphics.textboxwrap(2);
graphics.textboxcentertext();
graphics.textboxpad(1, 1);
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
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
if(cl.numcrewmates()-crewmates()==0)
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
{
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(loc::gettext("All crewmates rescued!"), 50, 95+h, TEXT_COLOUR("gray"));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
char buffer[SCREEN_WIDTH_CHARS + 1];
loc::gettext_plural_fill(
buffer, sizeof(buffer),
"{n_crew|wordy} remain", "{n_crew|wordy} remains",
"n_crew:int",
cl.numcrewmates()-crewmates()
);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(buffer, 50, 95+h, TEXT_COLOUR("gray"));
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
}
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.textboxwrap(4);
graphics.textboxcentertext();
graphics.textboxpad(2, 2);
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;
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
}
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 locking
2022-12-07 00:20:48 +01:00
incstate();
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
}
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
if(cl.numcrewmates()-crewmates()==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if(map.custommodeforreal)
{
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEOUT;
state locking
2022-12-07 00:20:48 +01:00
setstate(1014);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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();
Prevent other cases of losing unsaved levels by returning to menu 2.3 already made it so that if you ran the `rollcredits` command during in-editor playtesting, you wouldn't be returned to the title screen while losing unsaved level changes. But there are plenty of other ways to go back to the title screen from in-editor playtesting too. Namely, gamestate 1015 (the gamestate after completing a level) and 82 (time trial complete). So just add the appropriate checks to those gamestates, and add a catch-all check in Game::quittomenu(). Additionally, Game::updatecustomlevelstats() should not update custom level stats during in-editor playtesting (otherwise it would still happen even if the game didn't bring you back to the title screen). Editor notes will also be shown if the game prevents you from going to the title screen. Also, just to make things clear, I also added a level note for when the level is completed during in-editor playtesting. This is just to make it clear in cases where it might not be obvious that the game returned you to the editor for this reason. E.g. you have a terminal that calls gamestate(1013) in a level with 0 custom crewmates, but when you activate it, it looks like the terminal didn't work for some reason and just brought you back to the editor. But that's just only because you literally just completed the level.
2023-05-19 04:58:23 +02:00
ed.show_note(loc::gettext("Level completed"));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else
{
Don't check `!muted` when fading music after completion prompt This was done in 2.2 and previous probably to fix the fact that there were multiple conflicting audio controls (the player wants to mute the audio but the game wants to fade in the audio), but is now actively harmful since 2.3, because muting the game while finishing the completion prompt means the music will never come back in, even after unmuting. I also notice that when collecting a custom crewmate, the game checks for the level's start music instead of if there's actually a current song playing right now. I don't know why this was done, because it would've been better to copy-paste the trinket collection logic here. It's entirely possible for the audio to just be muted and never come back if the level has no start music but plays a song by using a script. Anyways, leaving it alone because it's quite possible that a level might be intentionally designed around this, I can't really tell the intentions of every level creator, and it's easy to work around (either don't use custom crewmates, which every modern level basically does nowadays, or just set the start music).
2021-09-11 00:46:14 +02:00
if (cl.levmusic > 0)
{
music.fadeMusicVolumeIn(3000);
}
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.showcutscenebars = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 1014:
frames--;
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 1015:
//Update level stats
Fix `special/stdin.vvvvvv` being saved to `levelstats.vvv` While fixing #885, I noticed that I had a bunch of `special/stdin.vvvvvv` entries saved in my `levelstats.vvv`. At once I knew that the dumb `special/stdin` hack that actually checks if the filename passed is `special/stdin` was to blame. STDIN playtesting was first merged, I knew in the back of my mind that it was a bit of a dumb hack, but I didn't know it would cause consequences like showing up in `levelstats.vvv`. For now, I'll just have to patch it, but hopefully in the future I'll remove the dumb hack entirely. Commenting both instances of the dumb hack with instructions to grep for it should help maintainers out.
2022-08-04 02:30:23 +02:00
/* FIXME: Have to add check to not save stats for the dumb hack
* `special/stdin.vvvvvv` filename... see elsewhere, grep for
* `special/stdin`! */
if(cl.numcrewmates()-crewmates()==0 && customlevelfilename != "levels/special/stdin.vvvvvv")
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Finished level
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
if (trinkets() >= cl.numtrinkets())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//and got all the trinkets!
updatecustomlevelstats(customlevelfilename, 3);
}
else
{
updatecustomlevelstats(customlevelfilename, 1);
}
}
Remove NO_EDITOR/NO_CUSTOM_LEVELS, disable editor on Steam Deck This commit removes the `NO_EDITOR` and `NO_CUSTOM_LEVELS` defines, which cleans up the code a lot, and they weren't really needed anyways. This commit also disables the editor on the Steam Deck, and adds a program argument to re-enable the editor, `-enable-editor`.
2023-08-23 19:51:11 +02:00
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();
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PRESENTINGVVVVVV); //should be after quittomenu()
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 2500:
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PAUSE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Activating a teleporter (appear)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 2501:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
//we're done here!
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(5);
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.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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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 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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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;
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("Hello?", 125+24, 152-20, TEXT_COLOUR("cyan"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIRIDIAN);
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;
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextbox("Is anyone there?", 125+8, 152-24, TEXT_COLOUR("cyan"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_VIRIDIAN);
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_POTENTIALFORANYTHING);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3000:
//Activating a teleporter (long version for level complete)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(30);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3001:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3002:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3003:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3004:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
//we're done here!
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(50);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
switch(companion)
{
case 6:
state locking
2022-12-07 00:20:48 +01:00
setstate(3006);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break; //Warp Zone
case 7:
state locking
2022-12-07 00:20:48 +01:00
setstate(3020);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break; //Space Station
case 8:
state locking
2022-12-07 00:20:48 +01:00
setstate(3040);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break; //Lab
case 9:
state locking
2022-12-07 00:20:48 +01:00
setstate(3060);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break; //Tower
case 10:
state locking
2022-12-07 00:20:48 +01:00
setstate(3080);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break; //Intermission 2
case 11:
state locking
2022-12-07 00:20:48 +01:00
setstate(3085);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break; //Intermission 1
}
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
if (translator_exploring_allowtele)
{
Use setstate(n)/incstate()/setstatedelay(n) in localization changes This mirrors PR #917.
2022-12-31 16:01:11 +01:00
setstate(3090);
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +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.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)
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknum(Unlock_WARPZONE_COMPLETE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
lastsaved = 4;
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PATHCOMPLETE);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(75);
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
levelcomplete_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3007:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Finish implementing sprites in textboxes This commit adjusts the Y position for flip-mode, and makes the main game use this new system.
2023-08-11 02:41:39 +02:00
crewmate_textbox(13);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3008:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
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
remaining_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3009:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
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
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3010:
if (jumppressed)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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:
remove two-argument setstate
2022-12-08 02:10:12 +01:00
setstate(3070);
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3020:
//Level complete! (Space Station 2)
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknum(Unlock_SPACESTATION2_COMPLETE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
lastsaved = 2;
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PATHCOMPLETE);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(75);
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
levelcomplete_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3021:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Finish implementing sprites in textboxes This commit adjusts the Y position for flip-mode, and makes the main game use this new system.
2023-08-11 02:41:39 +02:00
crewmate_textbox(14);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3022:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
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
remaining_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3023:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
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
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3024:
if (jumppressed)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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:
remove two-argument setstate
2022-12-08 02:10:12 +01:00
setstate(3070);
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3040:
//Level complete! (Lab)
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknum(Unlock_LABORATORY_COMPLETE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
lastsaved = 5;
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PATHCOMPLETE);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(75);
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
levelcomplete_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3041:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Finish implementing sprites in textboxes This commit adjusts the Y position for flip-mode, and makes the main game use this new system.
2023-08-11 02:41:39 +02:00
crewmate_textbox(16);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3042:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
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
remaining_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3043:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
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
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3044:
if (jumppressed)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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:
remove two-argument setstate
2022-12-08 02:10:12 +01:00
setstate(3070);
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3050:
//Level complete! (Space Station 1)
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknum(Unlock_SPACESTATION1_COMPLETE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
lastsaved = 1;
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PATHCOMPLETE);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(75);
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
levelcomplete_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3051:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Finish implementing sprites in textboxes This commit adjusts the Y position for flip-mode, and makes the main game use this new system.
2023-08-11 02:41:39 +02:00
crewmate_textbox(20);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3052:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
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
remaining_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3053:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
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
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3054:
if (jumppressed)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEOUT;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(10);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3056:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 3060:
//Level complete! (Tower)
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknum(Unlock_TOWER_COMPLETE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
lastsaved = 3;
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PATHCOMPLETE);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(75);
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
levelcomplete_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3061:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Finish implementing sprites in textboxes This commit adjusts the Y position for flip-mode, and makes the main game use this new system.
2023-08-11 02:41:39 +02:00
crewmate_textbox(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3062:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
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
remaining_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3063:
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
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
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3064:
if (jumppressed)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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:
remove two-argument setstate
2022-12-08 02:10:12 +01:00
setstate(3070);
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3070:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEOUT;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3071:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
}
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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;
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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;
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
startscript = true;
newscript="regularreturn";
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 3080:
//returning from an intermission, very like 3070
if (inintermission)
{
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEOUT;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
companion = 0;
state locking
2022-12-07 00:20:48 +01:00
setstate(3100);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknum(Unlock_INTERMISSION2_COMPLETE);
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEOUT;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
companion = 0;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 3081:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3082:
map.finalmode = false;
startscript = true;
newscript="regularreturn";
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3085:
//returning from an intermission, very like 3070
//return to menu from here
if (inintermission)
{
companion = 0;
supercrewmate = false;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEOUT;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.fadeout();
state locking
2022-12-07 00:20:48 +01:00
setstate(3100);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknum(Unlock_INTERMISSION1_COMPLETE);
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEOUT;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
companion = 0;
supercrewmate = false;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 3086:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3087:
map.finalmode = false;
startscript = true;
newscript="regularreturn";
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
case 3090:
/* Teleporting in translator_exploring should be just like
* the intermission replays: simply return to the menu */
companion = 0;
supercrewmate = false;
graphics.fademode = FADE_START_FADEOUT;
music.fadeout();
Use setstate(n)/incstate()/setstatedelay(n) in localization changes This mirrors PR #917.
2022-12-31 16:01:11 +01:00
setstate(3100);
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
break;
case 3091:
/* Different Final Level ending for translator_exploring */
music.fadeout();
Use setstate(n)/incstate()/setstatedelay(n) in localization changes This mirrors PR #917.
2022-12-31 16:01:11 +01:00
incstate();
setstatedelay(60);
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
break;
case 3092:
graphics.fademode = FADE_START_FADEOUT;
Use setstate(n)/incstate()/setstatedelay(n) in localization changes This mirrors PR #917.
2022-12-31 16:01:11 +01:00
setstate(3100);
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 3100:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
}
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();
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PRESENTINGVVVVVV); //should be after quittomenu();
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3500:
music.fadeout();
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(120);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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");
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknum(UnlockTrophy_GAME_COMPLETE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
crewstats[0] = true;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(75);
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PLENARY);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Add `textimage` for `levelcomplete` and `gamecomplete` `levelcomplete` and `gamecomplete` were hardcoded using textbox colors which were offset by 1. This PR fixes that, no longer requiring slightly-off colors, and instead adding a new property to textboxes which tell the game to display either level complete or game complete.
2023-08-20 19:11:44 +02:00
graphics.createtextboxflipme("", -1, 12, TEXT_COLOUR("cyan"));
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
graphics.addline(" ");
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("");
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_8X8);
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();
Add `textimage` for `levelcomplete` and `gamecomplete` `levelcomplete` and `gamecomplete` were hardcoded using textbox colors which were offset by 1. This PR fixes that, no longer requiring slightly-off colors, and instead adding a new property to textboxes which tell the game to display either level complete or game complete.
2023-08-20 19:11:44 +02:00
graphics.setimage(TEXTIMAGE_GAMECOMPLETE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3502:
Simplify time formatting functions Here's my notes on all the existing functions and what kind of time formats they output: - Game::giventimestring(int hrs, int min, int sec) H:MM:SS MM:SS - Game::timestring() // uses game.hours/minutes/seconds H:MM:SS MM:SS - Game::partimestring() // uses game.timetrialpar (seconds) MM:SS - Game::resulttimestring() // uses game.timetrialresulttime (sec) + timetrialresultframes (1/30s) MM:SS.CC - Game::timetstring(int t) // t = seconds MM:SS - Game::timestringcenti(char* buffer, const size_t buffer_size) // uses game.hours/minutes/seconds/frames H:MM:SS.CC MM:SS.CC - UtilityClass::timestring(int t) // t = frames, 30 frames = 1 second S:CC M:SS:CC This is kind of a mess, and there's a lot of functions that do the same thing except using different variables. For localization, I also want translators to be able to localize all these time formats - many languages use the decimal comma instead of the decimal point (12:34,56) maybe some languages really prefer something like 1時02分11秒44瞬... Which I don't know to be correct, but it's good to be prepared for it and not restrict translators arbitrarily to only changing ":" and "." when we can start making the system better in the first place. I added a new function, UtilityClass::format_time. This is the place where all time formats come together, given the number of seconds and optionally frames. I have simplified the above-mentioned functions somewhat, but I haven't given them a complete refactor or renaming - I mainly made sure that they all use the same backend so I can make the formats consistent and properly localizable. (And before we start shoving more temporary char buffers everywhere just to get rid of the std::string's, maybe we need to think of a globally used working buffer of size SCREEN_WIDTH_CHARS+1, as a register of sorts, for when any line of text needs to be made or processed, then printed, and then goes unused. Maybe help.textrow, or something like that.) As for this commit, the available time formats are now more consistent and changed a little in some places. Leading zeroes for the first unit are now no longer included, time trial results and the Super Gravitron can now display hours when they went to 60 minutes before, and we now always use .CC instead of :CC. These are the formats: - H:MM:SS - H:MM:SS.CC - M:SS - M:SS.CC - S.CC (only used when always_minutes=false, for the Gravitrons) Here's what changes to the current functions: - Game::partimestring() is removed - it was used in two places, and could be replaced by game.timetstring(game.timetrialpar) - Game::giventimestring(h,m,s) and Game::timestring() are now wrappers for the other functions - The four remaining functions (Game::resulttimestring(), Game::timetstring(t), Game::timestringcenti(buffer, buffer_size) and UtilityClass::timestring(t)) are now wrappers for the "central function", UtilityClass::format_time. - UtilityClass::twodigits(int t) is now unused so it's also removed. - I also added int UtilityClass::hms_to_seconds(int h, int m, int s)
2021-12-25 17:13:46 +01:00
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Convert more statedelay assignments to function call
2022-12-08 00:58:18 +01:00
setstatedelay(45+15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(loc::gettext("All Crew Members Rescued!"), -1, 64, TEXT_COLOUR("transparent"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Fix centering of game complete texts if level font != interface font Textboxes created with graphics.createtextboxflipme() use PR_FONT_LEVEL by default, but can be overridden with graphics.textboxprintflags() to, for example, set PR_FONT_INTERFACE. This happens for the textboxes on the Game Complete screen, which use interface text. The textboxes are centered by setting the X position to -1 though, which means they're solely centered based on the width of the first line, in the level font (because the font hasn't been changed to the interface font yet). Normally, this isn't a problem, because in the main game (where the Game Complete screen usually appears), the level font is always equal to the interface font. However, in custom levels you can still get it (by calling gamestate 3500) and in that case some of the text may be misaligned. This change fixes that by adding graphics.textboxcenterx() to these textboxes. As far as I can tell, these are the only textboxes that are centered by just x=-1 despite changing the font afterwards.
2023-12-05 04:00:47 +01:00
graphics.textboxcenterx();
Simplify time formatting functions Here's my notes on all the existing functions and what kind of time formats they output: - Game::giventimestring(int hrs, int min, int sec) H:MM:SS MM:SS - Game::timestring() // uses game.hours/minutes/seconds H:MM:SS MM:SS - Game::partimestring() // uses game.timetrialpar (seconds) MM:SS - Game::resulttimestring() // uses game.timetrialresulttime (sec) + timetrialresultframes (1/30s) MM:SS.CC - Game::timetstring(int t) // t = seconds MM:SS - Game::timestringcenti(char* buffer, const size_t buffer_size) // uses game.hours/minutes/seconds/frames H:MM:SS.CC MM:SS.CC - UtilityClass::timestring(int t) // t = frames, 30 frames = 1 second S:CC M:SS:CC This is kind of a mess, and there's a lot of functions that do the same thing except using different variables. For localization, I also want translators to be able to localize all these time formats - many languages use the decimal comma instead of the decimal point (12:34,56) maybe some languages really prefer something like 1時02分11秒44瞬... Which I don't know to be correct, but it's good to be prepared for it and not restrict translators arbitrarily to only changing ":" and "." when we can start making the system better in the first place. I added a new function, UtilityClass::format_time. This is the place where all time formats come together, given the number of seconds and optionally frames. I have simplified the above-mentioned functions somewhat, but I haven't given them a complete refactor or renaming - I mainly made sure that they all use the same backend so I can make the formats consistent and properly localizable. (And before we start shoving more temporary char buffers everywhere just to get rid of the std::string's, maybe we need to think of a globally used working buffer of size SCREEN_WIDTH_CHARS+1, as a register of sorts, for when any line of text needs to be made or processed, then printed, and then goes unused. Maybe help.textrow, or something like that.) As for this commit, the available time formats are now more consistent and changed a little in some places. Leading zeroes for the first unit are now no longer included, time trial results and the Super Gravitron can now display hours when they went to 60 minutes before, and we now always use .CC instead of :CC. These are the formats: - H:MM:SS - H:MM:SS.CC - M:SS - M:SS.CC - S.CC (only used when always_minutes=false, for the Gravitrons) Here's what changes to the current functions: - Game::partimestring() is removed - it was used in two places, and could be replaced by game.timetstring(game.timetrialpar) - Game::giventimestring(h,m,s) and Game::timestring() are now wrappers for the other functions - The four remaining functions (Game::resulttimestring(), Game::timetstring(t), Game::timestringcenti(buffer, buffer_size) and UtilityClass::timestring(t)) are now wrappers for the "central function", UtilityClass::format_time. - UtilityClass::twodigits(int t) is now unused so it's also removed. - I also added int UtilityClass::hms_to_seconds(int h, int m, int s)
2021-12-25 17:13:46 +01:00
char buffer[SCREEN_WIDTH_CHARS + 1];
timestringcenti(buffer, sizeof(buffer));
savetime = buffer;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Simplify time formatting functions Here's my notes on all the existing functions and what kind of time formats they output: - Game::giventimestring(int hrs, int min, int sec) H:MM:SS MM:SS - Game::timestring() // uses game.hours/minutes/seconds H:MM:SS MM:SS - Game::partimestring() // uses game.timetrialpar (seconds) MM:SS - Game::resulttimestring() // uses game.timetrialresulttime (sec) + timetrialresultframes (1/30s) MM:SS.CC - Game::timetstring(int t) // t = seconds MM:SS - Game::timestringcenti(char* buffer, const size_t buffer_size) // uses game.hours/minutes/seconds/frames H:MM:SS.CC MM:SS.CC - UtilityClass::timestring(int t) // t = frames, 30 frames = 1 second S:CC M:SS:CC This is kind of a mess, and there's a lot of functions that do the same thing except using different variables. For localization, I also want translators to be able to localize all these time formats - many languages use the decimal comma instead of the decimal point (12:34,56) maybe some languages really prefer something like 1時02分11秒44瞬... Which I don't know to be correct, but it's good to be prepared for it and not restrict translators arbitrarily to only changing ":" and "." when we can start making the system better in the first place. I added a new function, UtilityClass::format_time. This is the place where all time formats come together, given the number of seconds and optionally frames. I have simplified the above-mentioned functions somewhat, but I haven't given them a complete refactor or renaming - I mainly made sure that they all use the same backend so I can make the formats consistent and properly localizable. (And before we start shoving more temporary char buffers everywhere just to get rid of the std::string's, maybe we need to think of a globally used working buffer of size SCREEN_WIDTH_CHARS+1, as a register of sorts, for when any line of text needs to be made or processed, then printed, and then goes unused. Maybe help.textrow, or something like that.) As for this commit, the available time formats are now more consistent and changed a little in some places. Leading zeroes for the first unit are now no longer included, time trial results and the Super Gravitron can now display hours when they went to 60 minutes before, and we now always use .CC instead of :CC. These are the formats: - H:MM:SS - H:MM:SS.CC - M:SS - M:SS.CC - S.CC (only used when always_minutes=false, for the Gravitrons) Here's what changes to the current functions: - Game::partimestring() is removed - it was used in two places, and could be replaced by game.timetstring(game.timetrialpar) - Game::giventimestring(h,m,s) and Game::timestring() are now wrappers for the other functions - The four remaining functions (Game::resulttimestring(), Game::timetstring(t), Game::timestringcenti(buffer, buffer_size) and UtilityClass::timestring(t)) are now wrappers for the "central function", UtilityClass::format_time. - UtilityClass::twodigits(int t) is now unused so it's also removed. - I also added int UtilityClass::hms_to_seconds(int h, int m, int s)
2021-12-25 17:13:46 +01:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
const char* label = loc::gettext("Trinkets Found:");
char buffer[SCREEN_WIDTH_CHARS + 1];
vformat_buf(buffer, sizeof(buffer),
loc::gettext("{gamecomplete_n_trinkets|wordy}"),
"gamecomplete_n_trinkets:int",
trinkets()
);
Accommodate for some limit breaks in Welsh Two changes: - The labels on the Game Complete! screen for number of trinkets/deaths /time etc have been moved two pixels to the right, and had their limits increased by 1 character - The inaccuate limit for "quit to main menu" has been increased
2023-06-20 00:22:31 +02:00
graphics.createtextboxflipme(label, 170-font::len(PR_FONT_INTERFACE, label), 84, TEXT_COLOUR("transparent"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(buffer, 180, 84, TEXT_COLOUR("transparent"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Convert more statedelay assignments to function call
2022-12-08 00:58:18 +01:00
setstatedelay(45+15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
const char* label = loc::gettext("Game Time:");
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;
Accommodate for some limit breaks in Welsh Two changes: - The labels on the Game Complete! screen for number of trinkets/deaths /time etc have been moved two pixels to the right, and had their limits increased by 1 character - The inaccuate limit for "quit to main menu" has been increased
2023-06-20 00:22:31 +02:00
graphics.createtextboxflipme(label, 170-font::len(PR_FONT_INTERFACE, label), 96, TEXT_COLOUR("transparent"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(tempstring, 180, 96, TEXT_COLOUR("transparent"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
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:
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(45);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
const char* label = loc::gettext("Total Flips:");
Accommodate for some limit breaks in Welsh Two changes: - The labels on the Game Complete! screen for number of trinkets/deaths /time etc have been moved two pixels to the right, and had their limits increased by 1 character - The inaccuate limit for "quit to main menu" has been increased
2023-06-20 00:22:31 +02:00
graphics.createtextboxflipme(label, 170-font::len(PR_FONT_INTERFACE, label), 123, TEXT_COLOUR("transparent"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(help.String(totalflips), 180, 123, TEXT_COLOUR("transparent"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 3506:
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Convert more statedelay assignments to function call
2022-12-08 00:58:18 +01:00
setstatedelay(45+15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
const char* label = loc::gettext("Total Deaths:");
Accommodate for some limit breaks in Welsh Two changes: - The labels on the Game Complete! screen for number of trinkets/deaths /time etc have been moved two pixels to the right, and had their limits increased by 1 character - The inaccuate limit for "quit to main menu" has been increased
2023-06-20 00:22:31 +02:00
graphics.createtextboxflipme(label, 170-font::len(PR_FONT_INTERFACE, label), 135, TEXT_COLOUR("transparent"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(help.String(deathcounts), 180, 135, TEXT_COLOUR("transparent"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Convert more statedelay assignments to function call
2022-12-08 00:58:18 +01:00
setstatedelay(45+15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Game.cpp: Make Game::updatestate translatable This mainly adds loc::gettext calls. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:35:26 +01:00
char buffer[SCREEN_WIDTH_CHARS + 1];
loc::gettext_plural_fill(
buffer, sizeof(buffer),
"Hardest Room (with {n_deaths} deaths)",
"Hardest Room (with {n_deaths} death)",
"n_deaths:int",
hardestroomdeaths
);
Unhardcode textbox colors in textbox arguments There's a few places where textboxes are constructed through code, but they pass in the color's RGB values in manually. This commit unhardcodes most of them them, replacing them with a color lookup. The ones that weren't changed are special cases, like `175, 174, 174`.
2023-03-18 23:11:49 +01:00
graphics.createtextboxflipme(buffer, -1, 158, TEXT_COLOUR("transparent"));
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Fix centering of game complete texts if level font != interface font Textboxes created with graphics.createtextboxflipme() use PR_FONT_LEVEL by default, but can be overridden with graphics.textboxprintflags() to, for example, set PR_FONT_INTERFACE. This happens for the textboxes on the Game Complete screen, which use interface text. The textboxes are centered by setting the X position to -1 though, which means they're solely centered based on the width of the first line, in the level font (because the font hasn't been changed to the interface font yet). Normally, this isn't a problem, because in the main game (where the Game Complete screen usually appears), the level font is always equal to the interface font. However, in custom levels you can still get it (by calling gamestate 3500) and in that case some of the text may be misaligned. This change fixes that by adding graphics.textboxcenterx() to these textboxes. As far as I can tell, these are the only textboxes that are centered by just x=-1 despite changing the font afterwards.
2023-12-05 04:00:47 +01:00
graphics.textboxcenterx();
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
graphics.createtextboxflipme(
loc::gettext_roomname(map.custommode, hardestroom_x, hardestroom_y, hardestroom.c_str(), hardestroom_specialname),
-1, 170, TEXT_COLOUR("transparent")
);
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
graphics.textboxprintflags(PR_FONT_INTERFACE);
Fix centering of game complete texts if level font != interface font Textboxes created with graphics.createtextboxflipme() use PR_FONT_LEVEL by default, but can be overridden with graphics.textboxprintflags() to, for example, set PR_FONT_INTERFACE. This happens for the textboxes on the Game Complete screen, which use interface text. The textboxes are centered by setting the X position to -1 though, which means they're solely centered based on the width of the first line, in the level font (because the font hasn't been changed to the interface font yet). Normally, this isn't a problem, because in the main game (where the Game Complete screen usually appears), the level font is always equal to the interface font. However, in custom levels you can still get it (by calling gamestate 3500) and in that case some of the text may be misaligned. This change fixes that by adding graphics.textboxcenterx() to these textboxes. As far as I can tell, these are the only textboxes that are centered by just x=-1 despite changing the font afterwards.
2023-12-05 04:00:47 +01:00
graphics.textboxcenterx();
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
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
actionprompt_textbox();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3509:
if (jumppressed)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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");
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknum(UnlockTrophy_FLIPMODE_COMPLETE);
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
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
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknum(UnlockTrophy_NODEATHMODE_COMPLETE);
remove two-argument setstate
2022-12-08 02:10:12 +01:00
setstate(3520);
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(120);
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Call savestatsandsettings after unlocking MotU This calls Game::savestatsandsettings() after unlocking Master of the Universe (the achievement for completing No Death Mode), instead of before. This is not a big deal since Game::savestatsandsettings() is called anyway whenever the game is gracefully closed since 2.3, but it helps to make sure people won't lose their achievement data.
2023-05-22 08:01:10 +02:00
savestatsandsettings();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(30);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3513:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3514:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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!
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(60);
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 3516:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEOUT;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3517:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(30);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 3518:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEIN;
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(30);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
map.finalmode = false;
map.final_colormode = false;
map.final_mapcol = 0;
map.final_colorframe = 0;
map.finalstretch = false;
Strip out old special roomname system This commit replaces the old system with the new one, making it much easier to edit the transforming and glitchy roomnames. Additionally, this syncs flag 72 to finalstretch. Co-authored-by: Misa Elizabeth Kai <infoteddy@infoteddy.info>
2023-02-18 00:52:57 +01:00
obj.flags[72] = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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;
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEOUT;
state locking
2022-12-07 00:20:48 +01:00
incstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3521:
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
if (graphics.fademode == FADE_FULLY_BLACK)
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
}
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);
state locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4000:
//Activating a teleporter (short version)
state locking
2022-12-07 00:20:48 +01:00
state++; // Increment manually -- gamestate modification might be locked at this point
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
statedelay = 10;
flashlight = 5;
screenshake = 10;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
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!
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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:
remove two-argument setstate
2022-12-08 02:10:12 +01:00
state = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
statedelay = 0;
teleport_to_new_area = true;
state locking
2022-12-07 00:20:48 +01:00
unlockstate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4010:
//Activating a teleporter (default appear)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4011:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(5);
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.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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
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 4020:
//Activating a teleporter (default appear)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4021:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(5);
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.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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4030:
//Activating a teleporter (default appear)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4031:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(5);
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.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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4040:
//Activating a teleporter (default appear)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4041:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(5);
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.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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4050:
//Activating a teleporter (default appear)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4051:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(5);
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.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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4060:
//Activating a teleporter (default appear)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4061:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(5);
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.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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4070:
//Activating a teleporter (special for final script, player has colour changed to match rescued crewmate)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4071:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(5);
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.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;
Refactor colors in internal commands Originally this started as a "deduplicate a bunch of duplicated code in script commands" PR, but as I was working on that, I discovered there's a lot more that needs to be done than just deduplication. Anything which needs a crewmate entity now calls `getcrewmanfromname(name)`, and anything which just needs the crewmate's color calls `getcolorfromname(name)`. This was done to make sure that everything works consistently and no copy/pasting is required. Next is the fallback; instead of giving up and doing various things when it can't find a specific color, it now attempts to treat the color name as an ID, and if it can't then it returns -1, where each individual command handles that return value. This means we can keep around AEM -- a bug used in custom levels -- by not doing anything with the return value if it's -1. Also, for some reason, there were two `crewcolour` functions, so I stripped out the one in entityclass and left (and modified) the one in the graphics class, since the graphics class also has the `crewcolourreal` function.
2021-09-01 00:09:51 +02:00
obj.entities[i].colour = graphics.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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
startscript = true;
newscript = "finallevel_teleporter";
break;
case 4080:
//Activating a teleporter (default appear)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4081:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(5);
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.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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4090:
//Activating a teleporter (default appear)
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(15);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 90;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_FLASH);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4091:
//Activating a teleporter 2
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
flashlight = 5;
screenshake = 0;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_TELEPORT);
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 locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(5);
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.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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
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
{
state locking
2022-12-07 00:20:48 +01:00
incstate();
Also lock statedelay
2022-12-07 00:35:06 +01:00
setstatedelay(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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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;
Strip out old special roomname system This commit replaces the old system with the new one, making it much easier to edit the transforming and glitchy roomnames. Additionally, this syncs flag 72 to finalstretch. Co-authored-by: Misa Elizabeth Kai <infoteddy@infoteddy.info>
2023-02-18 00:52:57 +01:00
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
hardestroom_x = roomx;
hardestroom_y = roomy;
hardestroom_finalstretch = map.finalstretch;
Strip out old special roomname system This commit replaces the old system with the new one, making it much easier to edit the transforming and glitchy roomnames. Additionally, this syncs flag 72 to finalstretch. Co-authored-by: Misa Elizabeth Kai <infoteddy@infoteddy.info>
2023-02-18 00:52:57 +01:00
if (map.roomname[0] == '\0')
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
hardestroom = map.hiddenname;
hardestroom_specialname = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Strip out old special roomname system This commit replaces the old system with the new one, making it much easier to edit the transforming and glitchy roomnames. Additionally, this syncs flag 72 to finalstretch. Co-authored-by: Misa Elizabeth Kai <infoteddy@infoteddy.info>
2023-02-18 00:52:57 +01:00
else
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
{
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
hardestroom = map.roomname;
hardestroom_specialname = map.roomname_special;
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
}
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
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("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;
}
Reset some stats that weren't being reset in deletestats This function now properly deletes the Super Gravitron record, the Super Gravitron rank, and the best game deaths. They were not being properly reset previously, meaning you would have to go into your save file to properly clean out your save data.
2021-09-11 03:02:52 +02:00
swnrecord = 0;
swnbestrank = 0;
`deletestats`: Properly reset `bestgamedeaths` While I was testing deleting data while you were in-game, I noticed that deleting data gave you all the "Win with less than X deaths" trophies, even if you never got any of them before deleting data. Well, it turns out that if you have the best game death count of 0, then you win every trophy, and if you have the best game death count of -1 then that means you haven't completed the game yet. This reset was added in e3bfc79d4a9e636b85aa4ed684931de1ef6f2eca, so at least it's not in 2.3, but I only have myself to blame for making this mistake. Whoops.
2021-12-18 08:30:51 +01:00
bestgamedeaths = -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"))
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Error deleting saves/settings.vvv");
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 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
{
Silence various warnings in builds removing content The MAKEANDPLAY, NO_CUSTOM_LEVELS, and NO_EDITOR defines remove content or features. However, they then raise several warnings because of some cases, functions, or variables that end up not being used. This silences them by using the UNUSED macro, or by adding a default catch-all case if the define is defined (so unhandled cases will still raise warnings in a build that doesn't have these defines).
2023-02-04 09:14:04 +01:00
#ifdef MAKEANDPLAY
UNUSED(t);
#else
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
}
Prevent writing stats/settings if they're not loaded This prevents writing to unlock.vvv or settings.vvv if the game hasn't made an attempt to load them yet. Otherwise, if the game aborted via VVV_exit() because of, say, failure to parse a graphics file, it would overwrite perfectly existing valid save data since it hasn't loaded it yet. Fixes #870.
2022-03-14 06:39:09 +01:00
static bool stats_loaded = false;
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
void Game::loadstats(struct 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;
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
tinyxml2::XMLElement* dataNode;
Prevent writing stats/settings if they're not loaded This prevents writing to unlock.vvv or settings.vvv if the game hasn't made an attempt to load them yet. Otherwise, if the game aborted via VVV_exit() because of, say, failure to parse a graphics file, it would overwrite perfectly existing valid save data since it hasn't loaded it yet. Fixes #870.
2022-03-14 06:39:09 +01:00
stats_loaded = true;
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
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);
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
return;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
if (doc.Error())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
vlog_error("Error parsing unlock.vvv: %s", doc.ErrorStr());
return;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
dataNode = hDoc
.FirstChildElement()
.FirstChildElement("Data")
.FirstChildElement()
.ToElement();
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
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
for (pElem = dataNode; pElem != NULL; 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
}
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
void Game::deserializesettings(tinyxml2::XMLElement* dataNode, struct 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
{
Rename stretch mode to scaling mode internally It's been long overdue that this variable be named properly. 2.2 added integer scaling mode (thanks Ethan), 2.3 renamed it to scaling mode. Now 2.4 will properly call it what it is so people won't be confused by it. The ScreenSettings struct member is renamed from stretch to scalingMode along with the Screen class member being renamed, as well as the toggleStretchMode function being renamed to toggleScalingMode as well. Unfortunately, due to compatibility, we can't change the <stretch> XML tag.
2021-12-23 04:54:59 +01:00
screen_settings->scalingMode = 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
Store display index of window to settings I have this annoying issue where the game will open on the wrong monitor in fullscreen mode, because that monitor is considered to be display 0, whereas the primary monitor I want is display 1. To mitigate this somewhat, the game now stores the display index that it was closed on, and will save it to settings. Then the next time the game opens, it will open on that display index. This should work pretty well as long as you aren't changing your monitor setup constantly. Of course, none of this applies if your window manager is busted. For example, on GNOME Wayland, which is what I use, in windowed mode the game will always open on the monitor the cursor is on, and it won't even be centered in the monitor. But it works fine if I use XWayland via SDL_VIDEODRIVER=x11.
2023-03-21 08:23:42 +01:00
if (SDL_strcmp(pKey, "window_display") == 0)
{
screen_settings->windowDisplay = 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, "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
}
Add unfocus audio pause option Some people prefer the 2.2 behavior where unfocusing pauses the game, but the music still plays. One such person is Trinket9 on the VVVVVV Discord server, who wanted it that way. The reason audio pausing was added in the first place was to prevent desyncing music in levels with cutscenes that synced to music. Rather than reverting it, let's add this option instead.
2021-08-05 21:20:05 +02:00
if (SDL_strcmp(pKey, "disableaudiopause") == 0)
{
disableaudiopause = 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, "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
{
Split glitchrunner mode into multiple versions Previously, turning glitchrunner mode on essentially locked you to emulating 2.0, and turning it off just meant normal 2.3 behavior. But what if you wanted 2.2 behavior instead? Well, that's what I had to ask when a TAS of mine would desync in 2.3 because of the two-frame delay fix (glitchrunner off), but would also desync because of 2.0 warp lines (glitchrunner on). What I've done is made it so there are three states to glitchrunner mode now: 2.0 (previously just the "on" state), 2.2 (previously a state you couldn't use), and "off". Furthermore, I made it an enum, so in case future versions of the game patch out more glitches, we can add them to the enum (and the only other thing we have to update is a lookup table in GlitchrunnerMode.c). Also, 2.2 glitches exist in 2.0, so you'll want to use GlitchrunnerMode_less_than_or_equal() to check glitchrunner version.
2021-08-05 02:09:49 +02:00
GlitchrunnerMode_set(GlitchrunnerMode_string_to_enum(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
}
Add in-game timer option (#790)
2021-08-05 23:31:20 +02:00
if (SDL_strcmp(pKey, "showingametimer") == 0)
{
showingametimer = 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, "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
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
if (SDL_strcmp(pKey, "lang") == 0)
{
loc::lang = std::string(pText);
}
if (SDL_strcmp(pKey, "lang_set") == 0)
{
loc::lang_set = help.Int(pText);
}
Add "English sprites" setting It'll start working in the next commit... See the description there. (This commit does not add the new strings to the language files, since Terry now added them separately in his own branch)
2023-10-02 02:44:13 +02:00
if (SDL_strcmp(pKey, "english_sprites") == 0)
{
loc::english_sprites = help.Int(pText);
}
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
if (SDL_strcmp(pKey, "new_level_font") == 0)
{
loc::new_level_font = std::string(pText);
}
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
if (SDL_strcmp(pKey, "roomname_translator") == 0 && loc::show_translator_menu)
{
roomname_translator::set_enabled(help.Int(pText));
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Fix regression with controller binds on first launch I noticed that in 2.3, the game would launch with default controller binds upon first launch (e.g. no pre-existing unlock.vvv or settings.vvv), but in 2.4, this wasn't the case, and the default binds would only be set the next time the game was launched. This would result in you being essentially unable to use the controller on first launch save for the analogue stick and D-pad to move between menu selections and move the player. Bisecting pointed to commit 3ef5248db93541f399e8220fe0280281881d8bd6 as the cause of the regression. It turns out returning early upon error or a file not existing didn't set the default controller binds, because they were done at the end of Game::deserializesettings(). But the binds would be set on the next launch because if the file didn't exist, a new file would be written, not with the default binds, but then the next launch would read the file, see there were no binds, and then set the default binds accordingly. To fix this, I made it so that the default controller binds are set when Game is initialized. That way, it covers all cases where the game can't read a settings file.
2023-04-15 20:14:35 +02:00
setdefaultcontrollerbuttons();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Call FS.syncfs on Emscripten (#838) Also, add a sync parameter to avoid calling syncfs too often. Calling syncfs twice in a row is both inefficient and leads to errors displaying twice. This allows us to bypass it when saving unlock.vvv as part of savestatsandsettings.
2021-09-02 19:19:51 +02:00
bool Game::savestats(bool sync /*= true*/)
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
{
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
struct ScreenSettings screen_settings;
Explicitly zero declared `struct ScreenSettings`s Performance cost is negligible and well worth being safe in case there are more members added in the future but we forget to initialize them.
2021-12-25 09:22:22 +01:00
SDL_zero(screen_settings);
Extern `gameScreen`, remove `screenbuffer` I know earlier I removed the gameScreen extern in favor of using screenbuffer, but that was only to be consistent. After further consideration, I have found that it's actually really stupid. There's no reason to be accessing it through screenbuffer, and it's probably an artifact of 2.0-2.2 passing stack-allocated otherwise-global classes everywhere through function arguments. Also, it leads to stupid bugs where screenbuffer could potentially be NULL, which has already resulted in various annoying crashes in the past. Although those could be fixed by simply initializing screenbuffer at the very top of main(), but, why not just scrap the whole thing anyway? So that's what I'm doing. As a nice side effect, I've removed the transitive include of Screen.h from Graphics.h. This could've been done already since it only includes it for the pointer anyway, but it's still good to do it now.
2021-12-25 08:56:47 +01:00
gameScreen.GetSettings(&screen_settings);
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
Call FS.syncfs on Emscripten (#838) Also, add a sync parameter to avoid calling syncfs too often. Calling syncfs twice in a row is both inefficient and leads to errors displaying twice. This allows us to bypass it when saving unlock.vvv as part of savestatsandsettings.
2021-09-02 19:19:51 +02:00
return savestats(&screen_settings, sync);
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
}
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
bool Game::savestats(const struct ScreenSettings* screen_settings, bool sync /*= true*/)
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;
Prevent writing stats/settings if they're not loaded This prevents writing to unlock.vvv or settings.vvv if the game hasn't made an attempt to load them yet. Otherwise, if the game aborted via VVV_exit() because of, say, failure to parse a graphics file, it would overwrite perfectly existing valid save data since it hasn't loaded it yet. Fixes #870.
2022-03-14 06:39:09 +01:00
bool already_exists;
if (!stats_loaded)
{
vlog_warn("Stats not loaded! Not writing unlock.vvv.");
return false;
}
already_exists = FILESYSTEM_loadTiXml2Document("saves/unlock.vvv", 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
if (!already_exists)
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("No unlock.vvv found. Creating new file");
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
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
else if (doc.Error())
{
vlog_error("Error parsing existing unlock.vvv: %s", doc.ErrorStr());
vlog_info("Creating new unlock.vvv");
}
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_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
Call FS.syncfs on Emscripten (#838) Also, add a sync parameter to avoid calling syncfs too often. Calling syncfs twice in a row is both inefficient and leads to errors displaying twice. This allows us to bypass it when saving unlock.vvv as part of savestatsandsettings.
2021-09-02 19:19:51 +02:00
return FILESYSTEM_saveTiXml2Document("saves/unlock.vvv", doc, sync);
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
}
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
{
Call FS.syncfs on Emscripten (#838) Also, add a sync parameter to avoid calling syncfs too often. Calling syncfs twice in a row is both inefficient and leads to errors displaying twice. This allows us to bypass it when saving unlock.vvv as part of savestatsandsettings.
2021-09-02 19:19:51 +02:00
const bool stats_saved = savestats(false);
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 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
}
}
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
void Game::serializesettings(tinyxml2::XMLElement* dataNode, const struct 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
Rename stretch mode to scaling mode internally It's been long overdue that this variable be named properly. 2.2 added integer scaling mode (thanks Ethan), 2.3 renamed it to scaling mode. Now 2.4 will properly call it what it is so people won't be confused by it. The ScreenSettings struct member is renamed from stretch to scalingMode along with the Screen class member being renamed, as well as the toggleStretchMode function being renamed to toggleScalingMode as well. Unfortunately, due to compatibility, we can't change the <stretch> XML tag.
2021-12-23 04:54:59 +01:00
xml::update_tag(dataNode, "stretch", screen_settings->scalingMode);
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
Store display index of window to settings I have this annoying issue where the game will open on the wrong monitor in fullscreen mode, because that monitor is considered to be display 0, whereas the primary monitor I want is display 1. To mitigate this somewhat, the game now stores the display index that it was closed on, and will save it to settings. Then the next time the game opens, it will open on that display index. This should work pretty well as long as you aren't changing your monitor setup constantly. Of course, none of this applies if your window manager is busted. For example, on GNOME Wayland, which is what I use, in windowed mode the game will always open on the monitor the cursor is on, and it won't even be centered in the monitor. But it works fine if I use XWayland via SDL_VIDEODRIVER=x11.
2023-03-21 08:23:42 +01:00
xml::update_tag(dataNode, "window_display", screen_settings->windowDisplay);
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 unfocus audio pause option Some people prefer the 2.2 behavior where unfocusing pauses the game, but the music still plays. One such person is Trinket9 on the VVVVVV Discord server, who wanted it that way. The reason audio pausing was added in the first place was to prevent desyncing music in levels with cutscenes that synced to music. Rather than reverting it, let's add this option instead.
2021-08-05 21:20:05 +02:00
xml::update_tag(dataNode, "disableaudiopause", (int) disableaudiopause);
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);
Split glitchrunner mode into multiple versions Previously, turning glitchrunner mode on essentially locked you to emulating 2.0, and turning it off just meant normal 2.3 behavior. But what if you wanted 2.2 behavior instead? Well, that's what I had to ask when a TAS of mine would desync in 2.3 because of the two-frame delay fix (glitchrunner off), but would also desync because of 2.0 warp lines (glitchrunner on). What I've done is made it so there are three states to glitchrunner mode now: 2.0 (previously just the "on" state), 2.2 (previously a state you couldn't use), and "off". Furthermore, I made it an enum, so in case future versions of the game patch out more glitches, we can add them to the enum (and the only other thing we have to update is a lookup table in GlitchrunnerMode.c). Also, 2.2 glitches exist in 2.0, so you'll want to use GlitchrunnerMode_less_than_or_equal() to check glitchrunner version.
2021-08-05 02:09:49 +02:00
xml::update_tag(
dataNode,
"glitchrunnermode",
GlitchrunnerMode_enum_to_string(GlitchrunnerMode_get())
);
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
Add in-game timer option (#790)
2021-08-05 23:31:20 +02:00
xml::update_tag(dataNode, "showingametimer", (int) showingametimer);
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);
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
xml::update_tag(dataNode, "lang", loc::lang.c_str());
xml::update_tag(dataNode, "lang_set", (int) loc::lang_set);
Add "English sprites" setting It'll start working in the next commit... See the description there. (This commit does not add the new strings to the language files, since Terry now added them separately in his own branch)
2023-10-02 02:44:13 +02:00
xml::update_tag(dataNode, "english_sprites", (int) loc::english_sprites);
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
xml::update_tag(dataNode, "new_level_font", loc::new_level_font.c_str());
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
xml::update_tag(dataNode, "roomname_translator", (int) roomname_translator::enabled);
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
Prevent writing stats/settings if they're not loaded This prevents writing to unlock.vvv or settings.vvv if the game hasn't made an attempt to load them yet. Otherwise, if the game aborted via VVV_exit() because of, say, failure to parse a graphics file, it would overwrite perfectly existing valid save data since it hasn't loaded it yet. Fixes #870.
2022-03-14 06:39:09 +01:00
static bool settings_loaded = false;
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
void Game::loadsettings(struct 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;
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* dataNode;
Prevent writing stats/settings if they're not loaded This prevents writing to unlock.vvv or settings.vvv if the game hasn't made an attempt to load them yet. Otherwise, if the game aborted via VVV_exit() because of, say, failure to parse a graphics file, it would overwrite perfectly existing valid save data since it hasn't loaded it yet. Fixes #870.
2022-03-14 06:39:09 +01:00
settings_loaded = true;
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_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);
Remove superfluous message if settings.vvv/unlock.vvv don't exist If settings.vvv doesn't exist, loadsettings() calls savesettings(), but savesettings() already prints a message if settings.vvv doesn't exist. So then the output would look like No settings.vvv found. Creating new file No settings.vvv found Which is clearly redundant. The same thing happens with unlock.vvv, but in that case the following prints instead No unlock.vvv found. Creating new file No Stats found. Assuming a new player
2021-03-24 02:35:38 +01:00
return;
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
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
if (doc.Error())
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
{
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
vlog_error("Error parsing settings.vvv: %s", doc.ErrorStr());
return;
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
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
dataNode = hDoc
.FirstChildElement()
.FirstChildElement("Data")
.FirstChildElement()
.ToElement();
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
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
{
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
struct ScreenSettings screen_settings;
Explicitly zero declared `struct ScreenSettings`s Performance cost is negligible and well worth being safe in case there are more members added in the future but we forget to initialize them.
2021-12-25 09:22:22 +01:00
SDL_zero(screen_settings);
Extern `gameScreen`, remove `screenbuffer` I know earlier I removed the gameScreen extern in favor of using screenbuffer, but that was only to be consistent. After further consideration, I have found that it's actually really stupid. There's no reason to be accessing it through screenbuffer, and it's probably an artifact of 2.0-2.2 passing stack-allocated otherwise-global classes everywhere through function arguments. Also, it leads to stupid bugs where screenbuffer could potentially be NULL, which has already resulted in various annoying crashes in the past. Although those could be fixed by simply initializing screenbuffer at the very top of main(), but, why not just scrap the whole thing anyway? So that's what I'm doing. As a nice side effect, I've removed the transitive include of Screen.h from Graphics.h. This could've been done already since it only includes it for the pointer anyway, but it's still good to do it now.
2021-12-25 08:56:47 +01:00
gameScreen.GetSettings(&screen_settings);
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
return savesettings(&screen_settings);
}
De-C++-ify `struct ScreenSettings` This includes: - Removing the constructor in favor of actually being able to see that there's an actual function called being made initializing the struct - Removing the use of a reference in Screen::init() in favor of using a pointer - Adding the struct qualifier everywhere (it's not much typing), although technically you could typedef it in C, but I'd rather much not typedef just to remove a tag qualifier
2021-12-25 09:18:51 +01:00
bool Game::savesettings(const struct 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;
Prevent writing stats/settings if they're not loaded This prevents writing to unlock.vvv or settings.vvv if the game hasn't made an attempt to load them yet. Otherwise, if the game aborted via VVV_exit() because of, say, failure to parse a graphics file, it would overwrite perfectly existing valid save data since it hasn't loaded it yet. Fixes #870.
2022-03-14 06:39:09 +01:00
bool already_exists;
if (!settings_loaded)
{
vlog_warn("Settings not loaded! Not writing settings.vvv.");
return false;
}
already_exists = FILESYSTEM_loadTiXml2Document("saves/settings.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
if (!already_exists)
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("No settings.vvv found. Creating new file");
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
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
else if (doc.Error())
{
vlog_error("Error parsing existing settings.vvv: %s", doc.ErrorStr());
vlog_info("Creating new settings.vvv");
}
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_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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
deathseq = -1;
lifeseq = 0;
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
if (!nocutscenes)
{
music.play(Music_PAUSE);
}
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::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;
Fix bug: Playing music during Game Over screen This fixes a long-standing bug where it's possible to play music during the Game Over screen in No Death Mode. All you have to do is die while music is fading out from one area to the next. The easiest way to do this is in the entrance to Space Station 2, since there's a music change to Passion for Exploring in Outer Hull (you will need to go into the zone far enough to activate Pushing Onwards first), which also contains spikes to die on. Basically, it's a simple oversight because the nicefade system relies on music fading out to start playing the next track, but in this case, No Death Mode fades the music out without accounting for that. It's best to just disable nicefade entirely when dying in No Death Mode. Thanks to KSS for reporting this bug.
2023-05-22 08:27:33 +02:00
/* Fix a bug being able to play music on the Game Over screen */
music.nicefade = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
deathcounts++;
Use enums for sound effects This adds an anonymous enum for sound effects and replaces all calls to music.playef that use integer literals. This is not a named enum (that can be used for strict typechecking) because sound effect IDs are essentially part of the API of the game - many custom levels use these numbers. This is just to make the source code more readable without needing a comment to denote what number is what sound.
2023-06-04 00:29:02 +02:00
music.playef(Sound_CRY);
Disable more flashing elements if a11y is on For some reason, the accessibility option that was meant to disable flashes doesn't disable ALL flashes, only screen flashes and screen shaking. This commit disables a lot more, most importantly randomness in colors, the player flashing on death/respawn, and teleporters flashing.
2023-04-06 01:45:40 +02:00
if (INBOUNDS_VEC(i, obj.entities) && !noflashingmode)
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
}
}
Disable more flashing elements if a11y is on For some reason, the accessibility option that was meant to disable flashes doesn't disable ALL flashes, only screen flashes and screen shaking. This commit disables a lot more, most importantly randomness in colors, the player flashing on death/respawn, and teleporters flashing.
2023-04-06 01:45:40 +02:00
if (INBOUNDS_VEC(i, obj.entities) && !noflashingmode)
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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 locking
2022-12-07 00:20:48 +01:00
setstate(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
readmaingamesave("qsave.vvv", doc);
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
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
void Game::readmaingamesave(const char* savename, tinyxml2::XMLDocument& doc)
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
{
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;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
if (doc.Error())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
vlog_error("Error parsing %s: %s", savename, doc.ErrorStr());
return;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
/* Even if we want the default hardest room to be Welcome Aboard, there are pre-2.4
* saves with JUST <hardestroom> which should take priority over the coords */
hardestroom_x = -1;
hardestroom_y = -1;
hardestroom_specialname = false;
hardestroom_finalstretch = false;
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
for (pElem = hDoc
.FirstChildElement()
.FirstChildElement("Data")
.FirstChildElement()
.ToElement();
pElem != NULL;
pElem = pElem->NextSiblingElement())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
const char* pKey = pElem->Value();
const char* pText = pElem->GetText();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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, "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
}
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
else if (SDL_strcmp(pKey, "hardestroom_x") == 0)
{
hardestroom_x = help.Int(pText);
}
else if (SDL_strcmp(pKey, "hardestroom_y") == 0)
{
hardestroom_y = help.Int(pText);
}
else if (SDL_strcmp(pKey, "hardestroom_specialname") == 0)
{
hardestroom_specialname = help.Int(pText);
}
else if (SDL_strcmp(pKey, "hardestroom_finalstretch") == 0)
{
hardestroom_finalstretch = 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
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
}
Use `const std::string&` where possible in function params If it's at all possible to use `const std::string&` when passing `std::string`s around, then we use it. This is to limit the amount of memory usage as a result of the frequent use of `std::string`s, so the game no longer unnecessarily copies strings when it doesn't need to.
2021-09-07 00:41:49 +02:00
void Game::customloadquick(const std::string& savfile)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
tinyxml2::XMLDocument doc;
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
std::string levelfile;
if (cliplaytest)
{
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
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;
CLI: Allow no music to be played if save pos used If you provided any one of -playx, -playy, -playrx, -playry, -playgc, or -playmusic in command-line arguments for command-line playtesting, then the game would always try to play music, even if you passed a negative -playmusic. This wouldn't do anything in that case, unless you had MMMMMM installed, in which case it would play MMMMMM track 15 (Predestined Fate Final Level) due to the legacy wraparound bug. To fix this, only play music if the track provided is greater than -1. Additionally, to prevent it from playing Path Complete by default if you specify any of the other save position arguments but n ot -playmusic, it's now initialized to -1 instead of 0.
2023-06-10 20:41:32 +02:00
if (playmusic > -1)
{
music.play(playmusic);
}
Implement command-line playtesting (#163)
2020-04-09 21:03:24 +02:00
return;
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
levelfile = savfile.substr(7);
if (!FILESYSTEM_loadTiXml2Document(("saves/"+levelfile+".vvv").c_str(), doc))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
vlog_error("%s.vvv not found", levelfile.c_str());
return;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
if (doc.Error())
{
vlog_error("Error parsing %s.vvv: %s", levelfile.c_str(), doc.ErrorStr());
return;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
// Like readmaingamesave(...), old saves have just <hardestroom>
hardestroom_x = -1;
hardestroom_y = -1;
hardestroom_specialname = false;
hardestroom_finalstretch = false;
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
for (pElem = hDoc
.FirstChildElement()
.FirstChildElement("Data")
.FirstChildElement()
.ToElement();
pElem != NULL;
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
}
Rename `respawncolour` to `savecolour` Since it's a variable like saverx/savery/savex/savey, it should be renamed to savecolour and placed with all of them.
2021-09-07 03:28:28 +02:00
else if (SDL_strcmp(pKey, "savecolour") == 0)
{
savecolour = 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
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, "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
}
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
else if (SDL_strcmp(pKey, "hardestroom_x") == 0)
{
hardestroom_x = help.Int(pText);
}
else if (SDL_strcmp(pKey, "hardestroom_y") == 0)
{
hardestroom_y = help.Int(pText);
}
else if (SDL_strcmp(pKey, "hardestroom_specialname") == 0)
{
hardestroom_specialname = help.Int(pText);
}
else if (SDL_strcmp(pKey, "hardestroom_finalstretch") == 0)
{
hardestroom_finalstretch = 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
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
}
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
else if (SDL_strcmp(pKey, "lang_custom") == 0)
{
loc::lang_custom = pText;
if (pText[0] != '\0')
{
loc::loadtext_custom(NULL);
}
}
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
}
Add audiopause(on/off) command If you have unfocus pause off, and unfocus audio pause off, then this command will go into effect. When it's set to on, the audio will pause when you unfocus the game. When it's set to off, the audio will not. This is different from the setting, and gets saved to the save file.
2021-08-12 03:08:32 +02:00
else if (SDL_strcmp(pKey, "disabletemporaryaudiopause") == 0)
{
disabletemporaryaudiopause = help.Int(pText);
}
Save showtrinkets to custom level quicksaves Since custom levels have gained the functionality to show trinkets on the minimap, it's nice to just save the showtrinkets variable directly to the save file, without having to make level makers handle it themselves.
2021-06-14 02:24:16 +02:00
else if (SDL_strcmp(pKey, "showtrinkets") == 0)
{
map.showtrinkets = help.Int(pText);
}
Animated roomnames, setroomname command This commit adds a better system for animated roomnames. The old system, like many other systems, were very hardcoded, and can be described as mostly else-if chains, with some fun string comparisons. The new system uses lists of text for transformations and glitchy names, making it much easier to add new cases if needeed. This commit implements the system but does not replace the old system, where that is done in the next commit. The settings for special roomnames can be read from level XML, and `setroomname()` can be used from commands to set a new, static name.
2022-12-12 00:05:20 +01:00
else if (SDL_strcmp(pKey, "roomname") == 0)
{
map.setroomname(pText);
map.roomnameset = true;
map.roomname_special = true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
De-duplicate loadsummary parsing and move to different function I will need to be able to return from this function if there's an XML error, otherwise writing out the control flow manually gets really nasty. And while I'm at it, it's some a nice de-duplication as well. To do this, we create a temporary struct that bundles up all the information we want for the summary, and pass it in to the intermediate load function. Furthermore, we can get rid of reading map.finalstretch - it affects nothing. map.finalmode is still needed, however, because of the usage of map.area().
2021-03-24 00:43:02 +01:00
static void loadthissummary(
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
const char* filename,
Move `struct Summary` from Game.cpp to Game.h This will allow it to be used in other source files in a later commit.
2023-09-12 03:04:34 +02:00
struct Game::Summary* summary,
De-duplicate loadsummary parsing and move to different function I will need to be able to return from this function if there's an XML error, otherwise writing out the control flow manually gets really nasty. And while I'm at it, it's some a nice de-duplication as well. To do this, we create a temporary struct that bundles up all the information we want for the summary, and pass it in to the intermediate load function. Furthermore, we can get rid of reading map.finalstretch - it affects nothing. map.finalmode is still needed, however, because of the usage of map.area().
2021-03-24 00:43:02 +01:00
tinyxml2::XMLDocument& doc
) {
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
if (doc.Error())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
vlog_error("Error parsing %s: %s", filename, doc.ErrorStr());
return;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
summary->exists = true;
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
for (pElem = hDoc
.FirstChildElement()
.FirstChildElement("Data")
.FirstChildElement()
.ToElement();
pElem != NULL;
pElem = pElem->NextSiblingElement())
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
De-duplicate loadsummary parsing and move to different function I will need to be able to return from this function if there's an XML error, otherwise writing out the control flow manually gets really nasty. And while I'm at it, it's some a nice de-duplication as well. To do this, we create a temporary struct that bundles up all the information we want for the summary, and pass it in to the intermediate load function. Furthermore, we can get rid of reading map.finalstretch - it affects nothing. map.finalmode is still needed, however, because of the usage of map.area().
2021-03-24 00:43:02 +01:00
const char* pKey = pElem->Value();
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
const char* pText = pElem->GetText();
if (pText == NULL)
{
pText = "";
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
if (SDL_strcmp(pKey, "seconds") == 0)
De-duplicate loadsummary parsing and move to different function I will need to be able to return from this function if there's an XML error, otherwise writing out the control flow manually gets really nasty. And while I'm at it, it's some a nice de-duplication as well. To do this, we create a temporary struct that bundles up all the information we want for the summary, and pass it in to the intermediate load function. Furthermore, we can get rid of reading map.finalstretch - it affects nothing. map.finalmode is still needed, however, because of the usage of map.area().
2021-03-24 00:43:02 +01:00
{
summary->seconds = help.Int(pText);
}
else if (SDL_strcmp(pKey, "minutes") == 0)
{
summary->minutes = help.Int(pText);
}
else if (SDL_strcmp(pKey, "hours") == 0)
{
summary->hours = help.Int(pText);
}
else if (SDL_strcmp(pKey, "saverx") == 0)
{
Change savex and savey in struct Summary to saverx and savery This is a bit misleading otherwise, since it is the room coordinates, not pixel coordinates.
2023-09-12 03:22:18 +02:00
summary->saverx = help.Int(pText);
De-duplicate loadsummary parsing and move to different function I will need to be able to return from this function if there's an XML error, otherwise writing out the control flow manually gets really nasty. And while I'm at it, it's some a nice de-duplication as well. To do this, we create a temporary struct that bundles up all the information we want for the summary, and pass it in to the intermediate load function. Furthermore, we can get rid of reading map.finalstretch - it affects nothing. map.finalmode is still needed, however, because of the usage of map.area().
2021-03-24 00:43:02 +01:00
}
else if (SDL_strcmp(pKey, "savery") == 0)
{
Change savex and savey in struct Summary to saverx and savery This is a bit misleading otherwise, since it is the room coordinates, not pixel coordinates.
2023-09-12 03:22:18 +02:00
summary->savery = help.Int(pText);
De-duplicate loadsummary parsing and move to different function I will need to be able to return from this function if there's an XML error, otherwise writing out the control flow manually gets really nasty. And while I'm at it, it's some a nice de-duplication as well. To do this, we create a temporary struct that bundles up all the information we want for the summary, and pass it in to the intermediate load function. Furthermore, we can get rid of reading map.finalstretch - it affects nothing. map.finalmode is still needed, however, because of the usage of map.area().
2021-03-24 00:43:02 +01:00
}
else if (SDL_strcmp(pKey, "trinkets") == 0)
{
summary->trinkets = help.Int(pText);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
De-duplicate loadsummary parsing and move to different function I will need to be able to return from this function if there's an XML error, otherwise writing out the control flow manually gets really nasty. And while I'm at it, it's some a nice de-duplication as well. To do this, we create a temporary struct that bundles up all the information we want for the summary, and pass it in to the intermediate load function. Furthermore, we can get rid of reading map.finalstretch - it affects nothing. map.finalmode is still needed, however, because of the usage of map.area().
2021-03-24 00:43:02 +01:00
LOAD_ARRAY_RENAME(crewstats, summary->crewstats)
}
}
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
De-duplicate loadsummary parsing and move to different function I will need to be able to return from this function if there's an XML error, otherwise writing out the control flow manually gets really nasty. And while I'm at it, it's some a nice de-duplication as well. To do this, we create a temporary struct that bundles up all the information we want for the summary, and pass it in to the intermediate load function. Furthermore, we can get rid of reading map.finalstretch - it affects nothing. map.finalmode is still needed, however, because of the usage of map.area().
2021-03-24 00:43:02 +01:00
void Game::loadsummary(void)
{
tinyxml2::XMLDocument doc;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
SDL_zero(last_telesave);
SDL_zero(last_quicksave);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
if (FILESYSTEM_loadTiXml2Document("saves/tsave.vvv", doc))
{
loadthissummary("tsave.vvv", &last_telesave, doc);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
if (FILESYSTEM_loadTiXml2Document("saves/qsave.vvv", doc))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
loadthissummary("qsave.vvv", &last_quicksave, 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::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)
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("No tsave.vvv found. Creating new file");
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
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
else if (doc.Error())
{
vlog_error("Error parsing existing tsave.vvv: %s", doc.ErrorStr());
vlog_info("Creating new tsave.vvv");
}
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
last_telesave = 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
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Could Not Save game!");
vlog_error("Failed: %s%s", 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
}
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("Game saved");
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 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)
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("No qsave.vvv found. Creating new file");
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
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
else if (doc.Error())
{
vlog_error("Error parsing existing qsave.vvv: %s", doc.ErrorStr());
vlog_info("Creating new qsave.vvv");
}
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
last_quicksave = 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
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Could Not Save game!");
vlog_error("Failed: %s%s", 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
}
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("Game saved");
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
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
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
struct Game::Summary 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.
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
struct Game::Summary summary;
SDL_zero(summary);
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!
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
return summary;
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
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
int n_trinkets = trinkets();
xml::update_tag(msgs, "trinkets", n_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);
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);
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
xml::update_tag(msgs, "hardestroom_x", hardestroom_x);
xml::update_tag(msgs, "hardestroom_y", hardestroom_y);
xml::update_tag(msgs, "hardestroom_specialname", (int) hardestroom_specialname);
xml::update_tag(msgs, "hardestroom_finalstretch", (int) hardestroom_finalstretch);
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
Get rid of Game::savearea (std::string) This is what got saved to the area part of the <summary> tags, and it was specifically set upon pressing ACTION to save in the map menu. Which meant tsave.vvv may not get an accurate area name (notably "nowhere" if you hadn't quicksaved before in that session) even though it's not displayed anywhere so it didn't really matter. But this variable can be removed - there's only one place where <summary> is written for both quicksaves and telesaves, so that now gets the area at saving time. Fun fact: custom level quicksaves also have a <summary> tag, and it's even less functional than the one in tsave.vvv, because it stores whatever main-game area name applies to your current coordinates. So I simply filled in the level's name instead (just like what the actual save box says).
2023-09-12 04:15:12 +02:00
std::string legacy_summary = std::string(map.currentarea(saverx, savery)) + ", " + timestring();
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
xml::update_tag(msgs, "summary", legacy_summary.c_str());
summary.exists = true;
summary.seconds = seconds;
summary.minutes = minutes;
summary.hours = hours;
summary.saverx = saverx;
summary.savery = savery;
summary.trinkets = n_trinkets;
SDL_memcpy(summary.crewstats, crewstats, sizeof(summary.crewstats));
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
Use `const std::string&` where possible in function params If it's at all possible to use `const std::string&` when passing `std::string`s around, then we use it. This is to limit the amount of memory usage as a result of the frequent use of `std::string`s, so the game no longer unnecessarily copies strings when it doesn't need to.
2021-09-07 00:41:49 +02:00
bool Game::customsavequick(const 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)
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("No %s.vvv found. Creating new file", levelfile.c_str());
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
}
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
else if (doc.Error())
{
vlog_error("Error parsing existing %s.vvv: %s", levelfile.c_str(), doc.ErrorStr());
vlog_info("Creating new %s.vvv", levelfile.c_str());
}
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_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
Rename `respawncolour` to `savecolour` Since it's a variable like saverx/savery/savex/savey, it should be renamed to savecolour and placed with all of them.
2021-09-07 03:28:28 +02:00
xml::update_tag(msgs, "savecolour", savecolour);
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 localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
xml::update_tag(msgs, "lang_custom", loc::lang_custom.c_str());
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);
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);
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
xml::update_tag(msgs, "hardestroom_x", hardestroom_x);
xml::update_tag(msgs, "hardestroom_y", hardestroom_y);
xml::update_tag(msgs, "hardestroom_specialname", (int) hardestroom_specialname);
xml::update_tag(msgs, "hardestroom_finalstretch", (int) hardestroom_finalstretch);
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
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
Add audiopause(on/off) command If you have unfocus pause off, and unfocus audio pause off, then this command will go into effect. When it's set to on, the audio will pause when you unfocus the game. When it's set to off, the audio will not. This is different from the setting, and gets saved to the save file.
2021-08-12 03:08:32 +02:00
xml::update_tag(msgs, "disabletemporaryaudiopause", (int) disabletemporaryaudiopause);
Save showtrinkets to custom level quicksaves Since custom levels have gained the functionality to show trinkets on the minimap, it's nice to just save the showtrinkets variable directly to the save file, without having to make level makers handle it themselves.
2021-06-14 02:24:16 +02:00
xml::update_tag(msgs, "showtrinkets", (int) map.showtrinkets);
Animated roomnames, setroomname command This commit adds a better system for animated roomnames. The old system, like many other systems, were very hardcoded, and can be described as mostly else-if chains, with some fun string comparisons. The new system uses lists of text for transformations and glitchy names, making it much easier to add new cases if needeed. This commit implements the system but does not replace the old system, where that is done in the next commit. The settings for special roomnames can be read from level XML, and `setroomname()` can be used from commands to set a new, static name.
2022-12-12 00:05:20 +01:00
if (map.roomnameset)
{
xml::update_tag(msgs, "roomname", map.roomname);
}
Strip out old special roomname system This commit replaces the old system with the new one, making it much easier to edit the transforming and glitchy roomnames. Additionally, this syncs flag 72 to finalstretch. Co-authored-by: Misa Elizabeth Kai <infoteddy@infoteddy.info>
2023-02-18 00:52:57 +01:00
else
{
// If there's roomname tags, remove them. There will probably only always be one, but just in case...
tinyxml2::XMLElement* element;
while ((element = msgs->FirstChildElement("roomname")) != NULL)
{
doc.DeleteNode(element);
}
}
Animated roomnames, setroomname command This commit adds a better system for animated roomnames. The old system, like many other systems, were very hardcoded, and can be described as mostly else-if chains, with some fun string comparisons. The new system uses lists of text for transformations and glitchy names, making it much easier to add new cases if needeed. This commit implements the system but does not replace the old system, where that is done in the next commit. The settings for special roomnames can be read from level XML, and `setroomname()` can be used from commands to set a new, static name.
2022-12-12 00:05:20 +01:00
Get rid of Game::savearea (std::string) This is what got saved to the area part of the <summary> tags, and it was specifically set upon pressing ACTION to save in the map menu. Which meant tsave.vvv may not get an accurate area name (notably "nowhere" if you hadn't quicksaved before in that session) even though it's not displayed anywhere so it didn't really matter. But this variable can be removed - there's only one place where <summary> is written for both quicksaves and telesaves, so that now gets the area at saving time. Fun fact: custom level quicksaves also have a <summary> tag, and it's even less functional than the one in tsave.vvv, because it stores whatever main-game area name applies to your current coordinates. So I simply filled in the level's name instead (just like what the actual save box says).
2023-09-12 04:15:12 +02:00
std::string legacy_summary = customleveltitle + ", " + timestring();
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
xml::update_tag(msgs, "summary", legacy_summary.c_str());
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/"+levelfile+".vvv").c_str(), doc))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Could Not Save game!");
vlog_error("Failed: %s%s%s", 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
}
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_info("Game saved");
Add error message if quicksave fails
2020-11-04 03:45:33 +01:00
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
Simplify and print XML errors from TinyXML-2 All XML functions now check the return value of tinyxml2::XMLDocument::Error() after each document gets loaded in to TinyXML-2. If there's an error, then all functions return. This isn't strictly necessary, but printing the error message that TinyXML-2 is the bare minimum we could do to be useful. Additionally, I've standardized the error messages of missing or corrupted XML files. Also, the way the game went about making the XML handles was... a bit roundabout. There were two XML handles, one for the document and one for the root element - although only one XML handle suffices. So I've cleaned that up too. I could've gone further and added error checking for a whole bunch of things (e.g. missing elements, missing attributes), but this is good enough. Also, if unlock.vvv or settings.vvv don't exist yet, the game is guaranteed to no-op instead of continuing with the function. Nothing bad seems to happen if the function continues, but the return statements should be there anyway to clearly indicate intent.
2021-03-24 02:44:16 +01:00
readmaingamesave("tsave.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
std::string Game::unrescued(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Randomly return the name of an unrescued crewmate
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
//Localization is handled with regular cutscene dialogue
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
{
Simplify time formatting functions Here's my notes on all the existing functions and what kind of time formats they output: - Game::giventimestring(int hrs, int min, int sec) H:MM:SS MM:SS - Game::timestring() // uses game.hours/minutes/seconds H:MM:SS MM:SS - Game::partimestring() // uses game.timetrialpar (seconds) MM:SS - Game::resulttimestring() // uses game.timetrialresulttime (sec) + timetrialresultframes (1/30s) MM:SS.CC - Game::timetstring(int t) // t = seconds MM:SS - Game::timestringcenti(char* buffer, const size_t buffer_size) // uses game.hours/minutes/seconds/frames H:MM:SS.CC MM:SS.CC - UtilityClass::timestring(int t) // t = frames, 30 frames = 1 second S:CC M:SS:CC This is kind of a mess, and there's a lot of functions that do the same thing except using different variables. For localization, I also want translators to be able to localize all these time formats - many languages use the decimal comma instead of the decimal point (12:34,56) maybe some languages really prefer something like 1時02分11秒44瞬... Which I don't know to be correct, but it's good to be prepared for it and not restrict translators arbitrarily to only changing ":" and "." when we can start making the system better in the first place. I added a new function, UtilityClass::format_time. This is the place where all time formats come together, given the number of seconds and optionally frames. I have simplified the above-mentioned functions somewhat, but I haven't given them a complete refactor or renaming - I mainly made sure that they all use the same backend so I can make the formats consistent and properly localizable. (And before we start shoving more temporary char buffers everywhere just to get rid of the std::string's, maybe we need to think of a globally used working buffer of size SCREEN_WIDTH_CHARS+1, as a register of sorts, for when any line of text needs to be made or processed, then printed, and then goes unused. Maybe help.textrow, or something like that.) As for this commit, the available time formats are now more consistent and changed a little in some places. Leading zeroes for the first unit are now no longer included, time trial results and the Super Gravitron can now display hours when they went to 60 minutes before, and we now always use .CC instead of :CC. These are the formats: - H:MM:SS - H:MM:SS.CC - M:SS - M:SS.CC - S.CC (only used when always_minutes=false, for the Gravitrons) Here's what changes to the current functions: - Game::partimestring() is removed - it was used in two places, and could be replaced by game.timetstring(game.timetrialpar) - Game::giventimestring(h,m,s) and Game::timestring() are now wrappers for the other functions - The four remaining functions (Game::resulttimestring(), Game::timetstring(t), Game::timestringcenti(buffer, buffer_size) and UtilityClass::timestring(t)) are now wrappers for the "central function", UtilityClass::format_time. - UtilityClass::twodigits(int t) is now unused so it's also removed. - I also added int UtilityClass::hms_to_seconds(int h, int m, int s)
2021-12-25 17:13:46 +01:00
return timetstring(help.hms_to_seconds(hrs, min, sec));
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::timestring(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Simplify time formatting functions Here's my notes on all the existing functions and what kind of time formats they output: - Game::giventimestring(int hrs, int min, int sec) H:MM:SS MM:SS - Game::timestring() // uses game.hours/minutes/seconds H:MM:SS MM:SS - Game::partimestring() // uses game.timetrialpar (seconds) MM:SS - Game::resulttimestring() // uses game.timetrialresulttime (sec) + timetrialresultframes (1/30s) MM:SS.CC - Game::timetstring(int t) // t = seconds MM:SS - Game::timestringcenti(char* buffer, const size_t buffer_size) // uses game.hours/minutes/seconds/frames H:MM:SS.CC MM:SS.CC - UtilityClass::timestring(int t) // t = frames, 30 frames = 1 second S:CC M:SS:CC This is kind of a mess, and there's a lot of functions that do the same thing except using different variables. For localization, I also want translators to be able to localize all these time formats - many languages use the decimal comma instead of the decimal point (12:34,56) maybe some languages really prefer something like 1時02分11秒44瞬... Which I don't know to be correct, but it's good to be prepared for it and not restrict translators arbitrarily to only changing ":" and "." when we can start making the system better in the first place. I added a new function, UtilityClass::format_time. This is the place where all time formats come together, given the number of seconds and optionally frames. I have simplified the above-mentioned functions somewhat, but I haven't given them a complete refactor or renaming - I mainly made sure that they all use the same backend so I can make the formats consistent and properly localizable. (And before we start shoving more temporary char buffers everywhere just to get rid of the std::string's, maybe we need to think of a globally used working buffer of size SCREEN_WIDTH_CHARS+1, as a register of sorts, for when any line of text needs to be made or processed, then printed, and then goes unused. Maybe help.textrow, or something like that.) As for this commit, the available time formats are now more consistent and changed a little in some places. Leading zeroes for the first unit are now no longer included, time trial results and the Super Gravitron can now display hours when they went to 60 minutes before, and we now always use .CC instead of :CC. These are the formats: - H:MM:SS - H:MM:SS.CC - M:SS - M:SS.CC - S.CC (only used when always_minutes=false, for the Gravitrons) Here's what changes to the current functions: - Game::partimestring() is removed - it was used in two places, and could be replaced by game.timetstring(game.timetrialpar) - Game::giventimestring(h,m,s) and Game::timestring() are now wrappers for the other functions - The four remaining functions (Game::resulttimestring(), Game::timetstring(t), Game::timestringcenti(buffer, buffer_size) and UtilityClass::timestring(t)) are now wrappers for the "central function", UtilityClass::format_time. - UtilityClass::twodigits(int t) is now unused so it's also removed. - I also added int UtilityClass::hms_to_seconds(int h, int m, int s)
2021-12-25 17:13:46 +01:00
return giventimestring(hours, minutes, seconds);
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::resulttimestring(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//given result time in seconds:
Simplify time formatting functions Here's my notes on all the existing functions and what kind of time formats they output: - Game::giventimestring(int hrs, int min, int sec) H:MM:SS MM:SS - Game::timestring() // uses game.hours/minutes/seconds H:MM:SS MM:SS - Game::partimestring() // uses game.timetrialpar (seconds) MM:SS - Game::resulttimestring() // uses game.timetrialresulttime (sec) + timetrialresultframes (1/30s) MM:SS.CC - Game::timetstring(int t) // t = seconds MM:SS - Game::timestringcenti(char* buffer, const size_t buffer_size) // uses game.hours/minutes/seconds/frames H:MM:SS.CC MM:SS.CC - UtilityClass::timestring(int t) // t = frames, 30 frames = 1 second S:CC M:SS:CC This is kind of a mess, and there's a lot of functions that do the same thing except using different variables. For localization, I also want translators to be able to localize all these time formats - many languages use the decimal comma instead of the decimal point (12:34,56) maybe some languages really prefer something like 1時02分11秒44瞬... Which I don't know to be correct, but it's good to be prepared for it and not restrict translators arbitrarily to only changing ":" and "." when we can start making the system better in the first place. I added a new function, UtilityClass::format_time. This is the place where all time formats come together, given the number of seconds and optionally frames. I have simplified the above-mentioned functions somewhat, but I haven't given them a complete refactor or renaming - I mainly made sure that they all use the same backend so I can make the formats consistent and properly localizable. (And before we start shoving more temporary char buffers everywhere just to get rid of the std::string's, maybe we need to think of a globally used working buffer of size SCREEN_WIDTH_CHARS+1, as a register of sorts, for when any line of text needs to be made or processed, then printed, and then goes unused. Maybe help.textrow, or something like that.) As for this commit, the available time formats are now more consistent and changed a little in some places. Leading zeroes for the first unit are now no longer included, time trial results and the Super Gravitron can now display hours when they went to 60 minutes before, and we now always use .CC instead of :CC. These are the formats: - H:MM:SS - H:MM:SS.CC - M:SS - M:SS.CC - S.CC (only used when always_minutes=false, for the Gravitrons) Here's what changes to the current functions: - Game::partimestring() is removed - it was used in two places, and could be replaced by game.timetstring(game.timetrialpar) - Game::giventimestring(h,m,s) and Game::timestring() are now wrappers for the other functions - The four remaining functions (Game::resulttimestring(), Game::timetstring(t), Game::timestringcenti(buffer, buffer_size) and UtilityClass::timestring(t)) are now wrappers for the "central function", UtilityClass::format_time. - UtilityClass::twodigits(int t) is now unused so it's also removed. - I also added int UtilityClass::hms_to_seconds(int h, int m, int s)
2021-12-25 17:13:46 +01:00
char output[SCREEN_WIDTH_CHARS + 1];
help.format_time(output, sizeof(output), timetrialresulttime, timetrialresultframes, true);
return output;
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::timetstring( int t )
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//given par time in seconds:
Simplify time formatting functions Here's my notes on all the existing functions and what kind of time formats they output: - Game::giventimestring(int hrs, int min, int sec) H:MM:SS MM:SS - Game::timestring() // uses game.hours/minutes/seconds H:MM:SS MM:SS - Game::partimestring() // uses game.timetrialpar (seconds) MM:SS - Game::resulttimestring() // uses game.timetrialresulttime (sec) + timetrialresultframes (1/30s) MM:SS.CC - Game::timetstring(int t) // t = seconds MM:SS - Game::timestringcenti(char* buffer, const size_t buffer_size) // uses game.hours/minutes/seconds/frames H:MM:SS.CC MM:SS.CC - UtilityClass::timestring(int t) // t = frames, 30 frames = 1 second S:CC M:SS:CC This is kind of a mess, and there's a lot of functions that do the same thing except using different variables. For localization, I also want translators to be able to localize all these time formats - many languages use the decimal comma instead of the decimal point (12:34,56) maybe some languages really prefer something like 1時02分11秒44瞬... Which I don't know to be correct, but it's good to be prepared for it and not restrict translators arbitrarily to only changing ":" and "." when we can start making the system better in the first place. I added a new function, UtilityClass::format_time. This is the place where all time formats come together, given the number of seconds and optionally frames. I have simplified the above-mentioned functions somewhat, but I haven't given them a complete refactor or renaming - I mainly made sure that they all use the same backend so I can make the formats consistent and properly localizable. (And before we start shoving more temporary char buffers everywhere just to get rid of the std::string's, maybe we need to think of a globally used working buffer of size SCREEN_WIDTH_CHARS+1, as a register of sorts, for when any line of text needs to be made or processed, then printed, and then goes unused. Maybe help.textrow, or something like that.) As for this commit, the available time formats are now more consistent and changed a little in some places. Leading zeroes for the first unit are now no longer included, time trial results and the Super Gravitron can now display hours when they went to 60 minutes before, and we now always use .CC instead of :CC. These are the formats: - H:MM:SS - H:MM:SS.CC - M:SS - M:SS.CC - S.CC (only used when always_minutes=false, for the Gravitrons) Here's what changes to the current functions: - Game::partimestring() is removed - it was used in two places, and could be replaced by game.timetstring(game.timetrialpar) - Game::giventimestring(h,m,s) and Game::timestring() are now wrappers for the other functions - The four remaining functions (Game::resulttimestring(), Game::timetstring(t), Game::timestringcenti(buffer, buffer_size) and UtilityClass::timestring(t)) are now wrappers for the "central function", UtilityClass::format_time. - UtilityClass::twodigits(int t) is now unused so it's also removed. - I also added int UtilityClass::hms_to_seconds(int h, int m, int s)
2021-12-25 17:13:46 +01:00
char output[SCREEN_WIDTH_CHARS + 1];
help.format_time(output, sizeof(output), t, -1, true);
return output;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add centiseconds to timer overlays This adds centiseconds to the in-game timer, as well as the time trial timer. This is to aid speedrun moderators in determining when exactly a run was completed, which they can't easily do if the timer only has a precision up to a second.
2021-12-21 02:32:12 +01:00
void Game::timestringcenti(char* buffer, const size_t buffer_size)
{
Simplify time formatting functions Here's my notes on all the existing functions and what kind of time formats they output: - Game::giventimestring(int hrs, int min, int sec) H:MM:SS MM:SS - Game::timestring() // uses game.hours/minutes/seconds H:MM:SS MM:SS - Game::partimestring() // uses game.timetrialpar (seconds) MM:SS - Game::resulttimestring() // uses game.timetrialresulttime (sec) + timetrialresultframes (1/30s) MM:SS.CC - Game::timetstring(int t) // t = seconds MM:SS - Game::timestringcenti(char* buffer, const size_t buffer_size) // uses game.hours/minutes/seconds/frames H:MM:SS.CC MM:SS.CC - UtilityClass::timestring(int t) // t = frames, 30 frames = 1 second S:CC M:SS:CC This is kind of a mess, and there's a lot of functions that do the same thing except using different variables. For localization, I also want translators to be able to localize all these time formats - many languages use the decimal comma instead of the decimal point (12:34,56) maybe some languages really prefer something like 1時02分11秒44瞬... Which I don't know to be correct, but it's good to be prepared for it and not restrict translators arbitrarily to only changing ":" and "." when we can start making the system better in the first place. I added a new function, UtilityClass::format_time. This is the place where all time formats come together, given the number of seconds and optionally frames. I have simplified the above-mentioned functions somewhat, but I haven't given them a complete refactor or renaming - I mainly made sure that they all use the same backend so I can make the formats consistent and properly localizable. (And before we start shoving more temporary char buffers everywhere just to get rid of the std::string's, maybe we need to think of a globally used working buffer of size SCREEN_WIDTH_CHARS+1, as a register of sorts, for when any line of text needs to be made or processed, then printed, and then goes unused. Maybe help.textrow, or something like that.) As for this commit, the available time formats are now more consistent and changed a little in some places. Leading zeroes for the first unit are now no longer included, time trial results and the Super Gravitron can now display hours when they went to 60 minutes before, and we now always use .CC instead of :CC. These are the formats: - H:MM:SS - H:MM:SS.CC - M:SS - M:SS.CC - S.CC (only used when always_minutes=false, for the Gravitrons) Here's what changes to the current functions: - Game::partimestring() is removed - it was used in two places, and could be replaced by game.timetstring(game.timetrialpar) - Game::giventimestring(h,m,s) and Game::timestring() are now wrappers for the other functions - The four remaining functions (Game::resulttimestring(), Game::timetstring(t), Game::timestringcenti(buffer, buffer_size) and UtilityClass::timestring(t)) are now wrappers for the "central function", UtilityClass::format_time. - UtilityClass::twodigits(int t) is now unused so it's also removed. - I also added int UtilityClass::hms_to_seconds(int h, int m, int s)
2021-12-25 17:13:46 +01:00
help.format_time(buffer, buffer_size, help.hms_to_seconds(hours, minutes, seconds), frames, true);
Add centiseconds to timer overlays This adds centiseconds to the in-game timer, as well as the time trial timer. This is to aid speedrun moderators in determining when exactly a run was completed, which they can't easily do if the timer only has a precision up to a second.
2021-12-21 02:32:12 +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::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())
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Error: returning to previous menu frame on empty stack!");
Add function Game::returnmenu() It simply goes to the previous menu stack frame.
2020-04-17 04:16:40 +02:00
return;
}
Kludge-fix being able to play music in editor When you're on the music changing screen in the editor, it plays the current track. When you return, it stops playing the track. However, if you press escape, it doesn't stop playing the track. This is because pressing escape just returns to the previous menu without stopping playing the track. To fix this, I just added some kludge in the return menu function. This is kinda super bad but it works for now and is just something to clean up later. Maybe like each menu having exit callbacks or something, I dunno. This is kinda a regression, kinda sorta not. In 2.2 and previous, pressing escape would just close the settings menu entirely, which also bypassed the music fadeout. 2.3 made it so pressing escape doesn't entirely close the settings menu, and just returns to the previous menu, which fails in a different way. But the intended way is definitely to select the return option and having the music fade out.
2021-09-11 03:56:12 +02:00
/* FIXME: Super bad kludge, don't hardcode this! */
if (currentmenuname == Menu::ed_music)
{
music.fadeout();
}
Add function Game::returnmenu() It simply goes to the previous menu stack frame.
2020-04-17 04:16:40 +02:00
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
{
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
if (t == Menu::mainmenu && !menutestmode)
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
{
//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:
Add asserts if `ingame_titlemode` in unexpected places The game will now assert if the main menu is created while ingame_titlemode is true, or if we attempt to load into a mode while it's true. And if assertions are disabled then it just stops doing it anyway. I don't think there's any way to get a glitched ingame_titlemode again, ever since I removed save data deletion taking you back to the main menu. But I've had enough bugs with the fact that we more-or-less use the same state for main menu options and in-game options, and that glitched ingame_titlemode bug DID just happen, so I'm taking precautions.
2021-12-18 08:36:13 +01:00
if (ingame_titlemode)
{
/* We shouldn't be here! */
SDL_assert(0 && "Entering main menu from in-game options!");
break;
}
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)
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("levels"));
option(loc::gettext("options"));
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
if (loc::show_translator_menu)
{
option(loc::gettext("translator"));
}
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("credits"));
option(loc::gettext("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;
case Menu::playerworlds:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("play a level"));
Remove NO_EDITOR/NO_CUSTOM_LEVELS, disable editor on Steam Deck This commit removes the `NO_EDITOR` and `NO_CUSTOM_LEVELS` defines, which cleans up the code a lot, and they weren't really needed anyways. This commit also disables the editor on the Steam Deck, and adds a program argument to re-enable the editor, `-enable-editor`.
2023-08-23 19:51:11 +02:00
option(loc::gettext("level editor"), !editor_disabled);
if (!editor_disabled)
{
option(loc::gettext("open level folder"), FILESYSTEM_openDirectoryEnabled());
option(loc::gettext("show level folder path"));
}
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("return"));
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;
Hide level path by default You will now need to go through another confirm menu in order to print your level path. The confirm menu warns you may leak sensitive information if you are streaming. Screenshots: https://i.imgur.com/0Dc9jsZ.png https://i.imgur.com/UhDgXqj.png https://i.imgur.com/Z0ftQnH.png Fixes #853.
2021-12-22 09:58:27 +01:00
case Menu::confirmshowlevelspath:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("no, don't show me"));
option(loc::gettext("yes, reveal the path"));
Hide level path by default You will now need to go through another confirm menu in order to print your level path. The confirm menu warns you may leak sensitive information if you are streaming. Screenshots: https://i.imgur.com/0Dc9jsZ.png https://i.imgur.com/UhDgXqj.png https://i.imgur.com/Z0ftQnH.png Fixes #853.
2021-12-22 09:58:27 +01:00
menuyoff = -10;
break;
case Menu::showlevelspath:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("return to levels"));
Hide level path by default You will now need to go through another confirm menu in order to print your level path. The confirm menu warns you may leak sensitive information if you are streaming. Screenshots: https://i.imgur.com/0Dc9jsZ.png https://i.imgur.com/UhDgXqj.png https://i.imgur.com/Z0ftQnH.png Fixes #853.
2021-12-22 09:58:27 +01:00
menuyoff = 60;
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::levellist:
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
if(cl.ListOfMetaData.size()==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("ok"));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
menuyoff = -20;
}
else
{
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
for(int i=0; i<(int) cl.ListOfMetaData.size(); i++) // FIXME: int/size_t! -flibit
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if(i>=levelpage*8 && i< (levelpage*8)+8)
{
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
const std::string filename = cl.ListOfMetaData[i].filename.substr(7);
int score = 0;
if (customlevelstats.count(filename) > 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
score = customlevelstats[filename];
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;
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
switch (score)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
case 0:
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;
Change levelstats data type from vector to map As described in #1016, there used to be a bug that inflated levelstats.vvv in 2.3, which was fixed in 2.4, but there was no way for inflated files to get smaller yet. This commit changes the storage of levelstats from a std::vector of structs to a std::map, so that uniqueness is guaranteed and thus the stats can be optimized automatically. And it also simplifies *and* optimizes the code that handles the levelstats - no more big loops that iterated over every element to find the matching level. (Farewell to the "life optimisation and all that" comment, too) I tested this with both my own levelstats.vvv, as well as some inflated ones (including Balneor's 93 MB one) and saw this code correctly reduce the filesize and speed up the levels list. Fixes #1016.
2023-10-25 04:05:23 +02:00
break;
}
case 1:
{
static const char tmp[] = " * ";
prefix = tmp;
break;
}
case 3:
{
static const char tmp[] = "** ";
prefix = tmp;
break;
}
default:
SDL_assert(0 && "Unhandled menu text prefix!");
prefix = "";
break;
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];
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
SDL_snprintf(text, sizeof(text), "%s%s", prefix, cl.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]);
}
Allow levels to select a font via XML, show correct font in levels list There still needs to be a menu for selecting a font, but it can now be loaded and saved correctly in the XML!
2023-01-20 03:56:17 +01:00
option(
text,
true,
cl.ListOfMetaData[i].title_is_gettext ? PR_FONT_INTERFACE : PR_FONT_IDX(
cl.ListOfMetaData[i].level_main_font_idx
)
);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
if (cl.ListOfMetaData.size() > 8)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
if((size_t) ((levelpage*8)+8) <cl.ListOfMetaData.size())
Don't show next/previous page options if only one page It's possible to get one page of levels by removing all the built-ins, either by removing them directly from data.zip or by putting files with the same filenames as them in your level folder that don't contain nothing. And hey, there's already a check for if no levels exist at all, so why not check for this too?
2021-08-12 04:48:40 +02:00
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("next page"));
Don't show next/previous page options if only one page It's possible to get one page of levels by removing all the built-ins, either by removing them directly from data.zip or by putting files with the same filenames as them in your level folder that don't contain nothing. And hey, there's already a check for if no levels exist at all, so why not check for this too?
2021-08-12 04:48:40 +02:00
}
else
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("first page"));
Don't show next/previous page options if only one page It's possible to get one page of levels by removing all the built-ins, either by removing them directly from data.zip or by putting files with the same filenames as them in your level folder that don't contain nothing. And hey, there's already a check for if no levels exist at all, so why not check for this too?
2021-08-12 04:48:40 +02:00
}
if (levelpage == 0)
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("last page"));
Don't show next/previous page options if only one page It's possible to get one page of levels by removing all the built-ins, either by removing them directly from data.zip or by putting files with the same filenames as them in your level folder that don't contain nothing. And hey, there's already a check for if no levels exist at all, so why not check for this too?
2021-08-12 04:48:40 +02:00
}
else
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("previous page"));
Don't show next/previous page options if only one page It's possible to get one page of levels by removing all the built-ins, either by removing them directly from data.zip or by putting files with the same filenames as them in your level folder that don't contain nothing. And hey, there's already a check for if no levels exist at all, so why not check for this too?
2021-08-12 04:48:40 +02: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
}
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("return"));
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;
case Menu::quickloadlevel:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("continue from save"));
option(loc::gettext("start from beginning"));
option(loc::gettext("delete save"));
option(loc::gettext("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;
Add being able to delete a custom level quicksave Custom level quicksaves are NOT affected by the clear data menu, so the player should be able to delete quicksaves this way. The quicksave confirmation menu now has an extra option to delete the save (and that option also has its own confirmation menu before deleting).
2021-08-12 05:26:58 +02:00
case Menu::deletequicklevel:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("no! don't delete"));
option(loc::gettext("yes, delete save"));
Add being able to delete a custom level quicksave Custom level quicksaves are NOT affected by the clear data menu, so the player should be able to delete quicksaves this way. The quicksave confirmation menu now has an extra option to delete the save (and that option also has its own confirmation menu before deleting).
2021-08-12 05:26:58 +02:00
menuyoff = 64;
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::youwannaquit:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("yes, quit"));
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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)
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (ingame_titlemode && unlock[Unlock_FLIPMODE])
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
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("flip mode"));
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
}
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("toggle fps"));
option(loc::gettext("speedrun options"));
option(loc::gettext("advanced options"));
option(loc::gettext("clear main game data"));
option(loc::gettext("clear custom level data"));
option(loc::gettext("return"));
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
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:
Add forced fullscreen mode This is mainly to make sure the game is definitely set to fullscreen in Big Picture and on the Steam Deck, and to also remove windowed options that wouldn't make sense if you're not on a desktop (toggling fullscreen, resize to nearest). Those options would also be removed on console and mobile too. There's a bit of an annoying bug where if you launch the game in forced fullscreen mode, but then exit and relaunch in normal mode, your game will have fullscreen window sizes but it won't be fullscreen. This is because forced fullscreen mode tries to preserve your non-forced fullscreen setting, but due to the way window sizes are stored and queried, it can't preserve the non-forced window size. This is a bit difficult to work around, so I'm just putting in a FIXME here because we can fix it later and I'd rather have a slightly buggy forced fullscreen mode than not have one at all. Closes #849.
2021-12-26 07:55:55 +01:00
if (!gameScreen.isForcedFullscreen())
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("toggle fullscreen"));
Add forced fullscreen mode This is mainly to make sure the game is definitely set to fullscreen in Big Picture and on the Steam Deck, and to also remove windowed options that wouldn't make sense if you're not on a desktop (toggling fullscreen, resize to nearest). Those options would also be removed on console and mobile too. There's a bit of an annoying bug where if you launch the game in forced fullscreen mode, but then exit and relaunch in normal mode, your game will have fullscreen window sizes but it won't be fullscreen. This is because forced fullscreen mode tries to preserve your non-forced fullscreen setting, but due to the way window sizes are stored and queried, it can't preserve the non-forced window size. This is a bit difficult to work around, so I'm just putting in a FIXME here because we can fix it later and I'd rather have a slightly buggy forced fullscreen mode than not have one at all. Closes #849.
2021-12-26 07:55:55 +01:00
}
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("scaling mode"));
Add forced fullscreen mode This is mainly to make sure the game is definitely set to fullscreen in Big Picture and on the Steam Deck, and to also remove windowed options that wouldn't make sense if you're not on a desktop (toggling fullscreen, resize to nearest). Those options would also be removed on console and mobile too. There's a bit of an annoying bug where if you launch the game in forced fullscreen mode, but then exit and relaunch in normal mode, your game will have fullscreen window sizes but it won't be fullscreen. This is because forced fullscreen mode tries to preserve your non-forced fullscreen setting, but due to the way window sizes are stored and queried, it can't preserve the non-forced window size. This is a bit difficult to work around, so I'm just putting in a FIXME here because we can fix it later and I'd rather have a slightly buggy forced fullscreen mode than not have one at all. Closes #849.
2021-12-26 07:55:55 +01:00
if (!gameScreen.isForcedFullscreen())
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("resize to nearest"), gameScreen.isWindowed);
Add forced fullscreen mode This is mainly to make sure the game is definitely set to fullscreen in Big Picture and on the Steam Deck, and to also remove windowed options that wouldn't make sense if you're not on a desktop (toggling fullscreen, resize to nearest). Those options would also be removed on console and mobile too. There's a bit of an annoying bug where if you launch the game in forced fullscreen mode, but then exit and relaunch in normal mode, your game will have fullscreen window sizes but it won't be fullscreen. This is because forced fullscreen mode tries to preserve your non-forced fullscreen setting, but due to the way window sizes are stored and queried, it can't preserve the non-forced window size. This is a bit difficult to work around, so I'm just putting in a FIXME here because we can fix it later and I'd rather have a slightly buggy forced fullscreen mode than not have one at all. Closes #849.
2021-12-26 07:55:55 +01:00
}
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("toggle filter"));
option(loc::gettext("toggle analogue"));
option(loc::gettext("toggle vsync"));
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("change description"));
option(loc::gettext("edit scripts"));
option(loc::gettext("change music"));
option(loc::gettext("editor ghosts"));
option(loc::gettext("load level"));
option(loc::gettext("save level"));
option(loc::gettext("options"));
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("change name"));
option(loc::gettext("change author"));
option(loc::gettext("change description"));
option(loc::gettext("change website"));
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
option(loc::gettext("change font"));
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("return"));
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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("next song"));
option(loc::gettext("previous song"));
option(loc::gettext("return"));
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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("yes, save and quit"));
option(loc::gettext("no, quit without saving"));
option(loc::gettext("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;
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
case Menu::ed_font:
{
int option_match = -1;
for (uint8_t i = 0; i < font::font_idx_options_n; i++)
{
uint8_t idx = font::font_idx_options[i];
option(font::get_main_font_display_name(idx), true, PR_FONT_IDX(idx));
if (font::level_font_is_main_idx(idx))
{
option_match = i;
}
}
currentmenuoption = option_match != -1 ? option_match : 0;
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::options:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("gameplay"));
option(loc::gettext("graphics"));
option(loc::gettext("audio"));
option(loc::gettext("game pad"));
option(loc::gettext("accessibility"));
Prevent changing language if a textbox is displayed I really thought I was going to need to block changing the language in-game altogether, but activity zone prompts are now fixed and the only obvious problem I can think of right now is having a dialogue open, so I just disable the language option if a textbox is displayed. (like how the map menu only has the save option if a script is running)
2023-08-31 04:36:46 +02:00
option(loc::gettext("language"), graphics.textboxes.empty());
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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;
break;
case Menu::speedrunneroptions:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("glitchrunner mode"));
option(loc::gettext("input delay"));
option(loc::gettext("interact button"));
option(loc::gettext("fake load screen"));
option(loc::gettext("toggle in-game timer"));
Add "English sprites" setting It'll start working in the next commit... See the description there. (This commit does not add the new strings to the language files, since Terry now added them separately in his own branch)
2023-10-02 02:44:13 +02:00
option(loc::gettext("english sprites"));
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("return"));
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
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;
Split glitchrunner mode into multiple versions Previously, turning glitchrunner mode on essentially locked you to emulating 2.0, and turning it off just meant normal 2.3 behavior. But what if you wanted 2.2 behavior instead? Well, that's what I had to ask when a TAS of mine would desync in 2.3 because of the two-frame delay fix (glitchrunner off), but would also desync because of 2.0 warp lines (glitchrunner on). What I've done is made it so there are three states to glitchrunner mode now: 2.0 (previously just the "on" state), 2.2 (previously a state you couldn't use), and "off". Furthermore, I made it an enum, so in case future versions of the game patch out more glitches, we can add them to the enum (and the only other thing we have to update is a lookup table in GlitchrunnerMode.c). Also, 2.2 glitches exist in 2.0, so you'll want to use GlitchrunnerMode_less_than_or_equal() to check glitchrunner version.
2021-08-05 02:09:49 +02:00
case Menu::setglitchrunner:
{
int i;
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("none"));
Split glitchrunner mode into multiple versions Previously, turning glitchrunner mode on essentially locked you to emulating 2.0, and turning it off just meant normal 2.3 behavior. But what if you wanted 2.2 behavior instead? Well, that's what I had to ask when a TAS of mine would desync in 2.3 because of the two-frame delay fix (glitchrunner off), but would also desync because of 2.0 warp lines (glitchrunner on). What I've done is made it so there are three states to glitchrunner mode now: 2.0 (previously just the "on" state), 2.2 (previously a state you couldn't use), and "off". Furthermore, I made it an enum, so in case future versions of the game patch out more glitches, we can add them to the enum (and the only other thing we have to update is a lookup table in GlitchrunnerMode.c). Also, 2.2 glitches exist in 2.0, so you'll want to use GlitchrunnerMode_less_than_or_equal() to check glitchrunner version.
2021-08-05 02:09:49 +02:00
for (i = 1; i < GlitchrunnerNumVersions; ++i)
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext(GlitchrunnerMode_enum_to_string((enum GlitchrunnerMode) i)));
Split glitchrunner mode into multiple versions Previously, turning glitchrunner mode on essentially locked you to emulating 2.0, and turning it off just meant normal 2.3 behavior. But what if you wanted 2.2 behavior instead? Well, that's what I had to ask when a TAS of mine would desync in 2.3 because of the two-frame delay fix (glitchrunner off), but would also desync because of 2.0 warp lines (glitchrunner on). What I've done is made it so there are three states to glitchrunner mode now: 2.0 (previously just the "on" state), 2.2 (previously a state you couldn't use), and "off". Furthermore, I made it an enum, so in case future versions of the game patch out more glitches, we can add them to the enum (and the only other thing we have to update is a lookup table in GlitchrunnerMode.c). Also, 2.2 glitches exist in 2.0, so you'll want to use GlitchrunnerMode_less_than_or_equal() to check glitchrunner version.
2021-08-05 02:09:49 +02:00
}
break;
}
Move some options to a new menu, "advanced options" VVVVVV's menus are kind of packed to the brim, so I thought it was time to recategorize the menus a little bit. There's now a new "advanced options" menu which holds the following options which were moved out of graphic options, game options and especially accessibility options: - toggle mouse - unfocus pause - fake load screen - room name background - glitchrunner mode I also made the positioning of the titles and descriptions more consistent, and made some options which were moved to the new menu not so abbreviated ("load screen" and "room name bg")
2020-06-30 22:06:19 +02:00
case Menu::advancedoptions:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("unfocus pause"));
option(loc::gettext("unfocus audio pause"));
option(loc::gettext("room name background"));
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("music volume"));
option(loc::gettext("sound volume"));
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
if (music.mmmmmm)
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("soundtrack"));
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
}
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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)
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("unlock play modes"));
Clean up of options menus for v2.3 (fixes #696)
2021-04-09 12:09:12 +02:00
#endif
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("invincibility"), !ingame_titlemode || !incompetitive());
option(loc::gettext("slowdown"), !ingame_titlemode || !incompetitive());
option(loc::gettext("animated backgrounds"));
option(loc::gettext("screen effects"));
option(loc::gettext("text outline"));
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("analog stick sensitivity"));
option(loc::gettext("bind flip"));
option(loc::gettext("bind enter"));
option(loc::gettext("bind menu"));
option(loc::gettext("bind restart"));
Show correct button glyph for interact if Enter/E are not split I thought 2.2 already had separate map and interact gamepad bindings, and they simply got neglected and broken with 2.3's split Enter/E key option. But actually, the new split Enter/E option also applied to gamepad buttons, and a separate interact binding was added, without really indicating anything if Enter and E are not split. And I guess using the same button for map and interact by default also makes sense for simplicity... This commit makes sure the button glyph displayed in-game is at least the correct button. The gamepad bindings menu is also slightly modified to darken the interact option - the button glyphs code now automatically causes them to show equal buttons anyway, so it wasn't too big of a change to also darken the line and disable the binding option. To me this says: "the interact key is fixed to be the same as enter right now, but there is a way to change it." It's still not ideal of course, and I know a similar change to the gamepad menu to hide the interact option was rejected a year ago because action sets would already fix it, but it's a year later now, and showing misleading button glyphs should be fixed in 2.4, whether it will already have action sets or not (And at this point I think the plan already is to keep the existing input system for 2.4) And it's a 3 line diff to darken and disable the option, compared to fully hiding the option.
2023-03-26 05:19:01 +02:00
option(loc::gettext("bind interact"), separate_interact);
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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;
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
case Menu::language:
if (loc::languagelist.empty())
{
option(loc::gettext("ok"));
menuyoff = -20;
}
else
{
for (size_t i = 0; i < loc::languagelist.size(); i++)
{
if (loc::languagelist[i].nativename.empty())
option(loc::languagelist[i].code.c_str());
else
Use languages' fonts for options on language screen
2023-01-15 04:06:31 +01:00
option(loc::languagelist[i].nativename.c_str(), true, PR_FONT_IDX(loc::languagelist[i].font_idx));
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
}
menuyoff = 70-(menuoptions.size()*10);
maxspacing = 5;
}
break;
case Menu::translator_main:
option(loc::gettext("translator options"));
option(loc::gettext("maintenance"));
option(loc::gettext("open lang folder"), FILESYSTEM_openDirectoryEnabled());
option(loc::gettext("return"));
menuyoff = 0;
break;
case Menu::translator_options:
option(loc::gettext("language statistics"));
option(loc::gettext("translate room names"));
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
option(loc::gettext("explore game"));
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
option(loc::gettext("menu test"));
Add cutscene test menu This allows translators to test all text boxes in the scripts. It doesn't run the scripts themselves - it only shows the basic appearance of each text box individually, so context may be lost but it's good to have a way to see any text boxes that might otherwise not be easily seen because they require specific circumstances to appear.
2022-12-24 04:16:56 +01:00
option(loc::gettext("cutscene test"), loc::lang != "en");
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
option(loc::gettext("limits check"));
option(loc::gettext("return"));
menuyoff = 0;
break;
case Menu::translator_options_limitscheck:
option(loc::gettext("next page"));
option(loc::gettext("return"));
menuyoff = 64;
break;
case Menu::translator_options_stats:
option(loc::gettext("return"));
menuyoff = 64;
break;
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
case Menu::translator_options_exploregame:
option(loc::gettext("space station 1"));
option(loc::gettext("the laboratory"));
option(loc::gettext("the tower"));
option(loc::gettext("space station 2"));
option(loc::gettext("the warp zone"));
option(loc::gettext("intermission 1"));
option(loc::gettext("intermission 2"));
option(loc::gettext("the final level"));
option(loc::gettext("return"));
menuyoff = -20;
break;
Add cutscene test menu This allows translators to test all text boxes in the scripts. It doesn't run the scripts themselves - it only shows the basic appearance of each text box individually, so context may be lost but it's good to have a way to see any text boxes that might otherwise not be easily seen because they require specific circumstances to appear.
2022-12-24 04:16:56 +01:00
case Menu::translator_options_cutscenetest:
for (
size_t i = (cutscenetest_menu_page*14);
i < (cutscenetest_menu_page*14)+14 && i < loc::testable_script_ids.size();
i++
)
{
option(loc::testable_script_ids[i].c_str());
}
if((cutscenetest_menu_page*14)+14 < loc::testable_script_ids.size())
{
option(loc::gettext("next page"));
}
else
{
option(loc::gettext("first page"));
}
if (cutscenetest_menu_page == 0)
{
option(loc::gettext("last page"));
}
else
{
option(loc::gettext("previous page"));
}
option(loc::gettext("from clipboard"));
option(loc::gettext("return"));
menuxoff = 20;
menuyoff = 55-(menuoptions.size()*10);
menuspacing = 5;
return; // skip automatic centering, will turn out bad with scripts list
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
case Menu::translator_maintenance:
option(loc::gettext("sync language files"));
option(loc::gettext("global statistics"), false);
option(loc::gettext("global limits check"));
option(loc::gettext("return"));
menuyoff = 0;
break;
case Menu::translator_maintenance_sync:
option(loc::gettext("sync"));
option(loc::gettext("return"));
menuyoff = 64;
break;
case Menu::translator_error_setlangwritedir:
option(loc::gettext("ok"));
menuyoff = 10;
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::cleardatamenu:
Add option to delete all custom level save data To match the option to nuke all main game save data, there is also now an option to nuke all custom level save data separately (which is just all custom level quicksaves, along with stars for level completion). It has its own confirmation menu too. It does not delete any levels from the levels folder.
2021-08-12 05:54:02 +02:00
case Menu::clearcustomdatamenu:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("no! don't delete"));
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("no, return to options"));
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("normal speed"));
option(loc::gettext("80% speed"));
option(loc::gettext("60% speed"));
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("unlock time trials"));
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
option(loc::gettext("unlock intermissions"), !unlock[Unlock_INTERMISSION_REPLAYS]);
option(loc::gettext("unlock no death mode"), !unlock[Unlock_NODEATHMODE]);
option(loc::gettext("unlock flip mode"), !unlock[Unlock_FLIPMODE]);
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("unlock ship jukebox"), (stat_trinkets<20));
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
option(loc::gettext("unlock secret lab"), !unlock[Unlock_SECRETLAB]);
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("next page"));
option(loc::gettext("last page"));
option(loc::gettext("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:
case Menu::credits25:
case Menu::credits3:
case Menu::credits4:
case Menu::credits5:
Add localisation credits to main menu credits In addition, this adds Ally and mothbeanie to the Localisation Implementation page credits. Also updated the game complete credits!
2023-12-06 00:34:05 +01:00
case Menu::credits_localisations_implementation:
case Menu::credits_localisations_translations:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("next page"));
option(loc::gettext("previous page"));
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("first page"));
option(loc::gettext("previous page"));
option(loc::gettext("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;
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (unlock[Unlock_SPACESTATION1_COMPLETE]
&& stat_trinkets >= 3
&& !unlocknotify[Unlock_TIMETRIAL_SPACESTATION1])
{
temp++;
}
if (unlock[Unlock_LABORATORY_COMPLETE]
&& stat_trinkets >= 6
&& !unlocknotify[Unlock_TIMETRIAL_LABORATORY])
{
temp++;
}
if (unlock[Unlock_TOWER_COMPLETE]
&& stat_trinkets >= 9
&& !unlocknotify[Unlock_TIMETRIAL_TOWER])
{
temp++;
}
if (unlock[Unlock_SPACESTATION2_COMPLETE]
&& stat_trinkets >= 12
&& !unlocknotify[Unlock_TIMETRIAL_SPACESTATION2])
{
temp++;
}
if (unlock[Unlock_WARPZONE_COMPLETE]
&& stat_trinkets >= 15
&& !unlocknotify[Unlock_TIMETRIAL_WARPZONE])
{
temp++;
}
if (unlock[UnlockTrophy_GAME_COMPLETE]
&& stat_trinkets >= 18
&& !unlocknotify[Unlock_TIMETRIAL_FINALLEVEL])
{
temp++;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (temp > 0)
{
//you've unlocked a time trial!
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (unlock[Unlock_SPACESTATION1_COMPLETE] && stat_trinkets >= 3)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknotify[Unlock_TIMETRIAL_SPACESTATION1] = true;
unlock[Unlock_TIMETRIAL_SPACESTATION1] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (unlock[Unlock_LABORATORY_COMPLETE] && stat_trinkets >= 6)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknotify[Unlock_TIMETRIAL_LABORATORY] = true;
unlock[Unlock_TIMETRIAL_LABORATORY] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (unlock[Unlock_TOWER_COMPLETE] && stat_trinkets >= 9)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknotify[Unlock_TIMETRIAL_TOWER] = true;
unlock[Unlock_TIMETRIAL_TOWER] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (unlock[Unlock_SPACESTATION2_COMPLETE] && stat_trinkets >= 12)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknotify[Unlock_TIMETRIAL_SPACESTATION2] = true;
unlock[Unlock_TIMETRIAL_SPACESTATION2] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (unlock[Unlock_WARPZONE_COMPLETE] && stat_trinkets >= 15)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknotify[Unlock_TIMETRIAL_WARPZONE] = true;
unlock[Unlock_TIMETRIAL_WARPZONE] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (unlock[UnlockTrophy_GAME_COMPLETE] && stat_trinkets >= 18)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknotify[Unlock_TIMETRIAL_FINALLEVEL] = true;
unlock[Unlock_TIMETRIAL_FINALLEVEL] = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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;
Use enums for time trial indexes This adds an anonymous enum for time trial indexes (e.g. the bestrank, bestlives, etc. arrays and timetriallevel), and replaces all integer literals with them. Just like the unlock arrays, these are indexes to an array in XML save files, so the numbers matter, and therefore should not use strict typechecking.
2023-06-06 02:50:19 +02:00
if (bestrank[TimeTrial_SPACESTATION1] >= 2) temp++;
if (bestrank[TimeTrial_LABORATORY] >= 2) temp++;
if (bestrank[TimeTrial_TOWER] >= 2) temp++;
if (bestrank[TimeTrial_SPACESTATION2] >= 2) temp++;
if (bestrank[TimeTrial_WARPZONE] >= 2) temp++;
if (bestrank[TimeTrial_FINALLEVEL] >= 2) temp++;
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (temp >= 4 && !unlocknotify[Unlock_NODEATHMODE])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Unlock No Death Mode
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlocknotify[Unlock_NODEATHMODE] = true;
unlock[Unlock_NODEATHMODE] = 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?
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
else if (unlock[UnlockTrophy_GAME_COMPLETE]
&& !unlocknotify[Unlock_FLIPMODE])
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
{
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlock[Unlock_FLIPMODE] = true;
unlocknotify[Unlock_FLIPMODE] = 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?
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
else if (unlock[Unlock_INTERMISSION2_COMPLETE]
&& !unlocknotify[Unlock_INTERMISSION_REPLAYS])
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
{
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
unlock[Unlock_INTERMISSION_REPLAYS] = true;
unlocknotify[Unlock_INTERMISSION_REPLAYS] = 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
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("continue"));
Make "start game" goto play menu if any unlocks, even if saves deleted This commit fixes a slightly frustrating thing where if you start a new game, and then exit before saving, "start game" will always take you to a new game, even though you have unlocked things like the Secret Lab or Time Trials. Now, if you select "new game" (only possible if you have something unlocked), then quit before saving, "start game" will still take you to the play menu, but "continue" is replaced with "start" and "new game" is gone.
2020-04-26 22:09:56 +02:00
}
else
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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:
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (unlock[Unlock_SECRETLAB])
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
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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
}
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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
{
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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
}
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("return"));
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
if (unlock[Unlock_SECRETLAB])
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
{
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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("proceed"));
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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("start new game"));
option(loc::gettext("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::playmodes:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("time trials"), !nocompetitive_unless_translator());
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
option(loc::gettext("intermissions"), unlock[Unlock_INTERMISSION_REPLAYS]);
option(loc::gettext("no death mode"), unlock[Unlock_NODEATHMODE] && !nocompetitive());
option(loc::gettext("flip mode"), unlock[Unlock_FLIPMODE]);
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("return"));
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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("play intermission 1"));
option(loc::gettext("play intermission 2"));
option(loc::gettext("return"));
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:
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
start_translator_exploring = false;
Add cases for intermission replay options, button fillers in editor The strings "Vitellary"/"Vermilion"/"Verdigris"/"Victoria" now have two cases to support changing them for the intermission replay menu options (like "with Vitellary"). Also, the string "< and > keys change tool" is now "{button1} and {button2} keys change tool", so it can be changed dynamically without having to retranslate the string.
2022-12-07 21:03:01 +01:00
option(loc::gettext_case("Vitellary", 1));
option(loc::gettext_case("Vermilion", 1));
option(loc::gettext_case("Verdigris", 1));
option(loc::gettext_case("Victoria", 1));
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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:
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
start_translator_exploring = false;
Add cases for intermission replay options, button fillers in editor The strings "Vitellary"/"Vermilion"/"Verdigris"/"Victoria" now have two cases to support changing them for the intermission replay menu options (like "with Vitellary"). Also, the string "< and > keys change tool" is now "{button1} and {button2} keys change tool", so it can be changed dynamically without having to retranslate the string.
2022-12-07 21:03:01 +01:00
option(loc::gettext_case("Vitellary", 1));
option(loc::gettext_case("Vermilion", 1));
option(loc::gettext_case("Verdigris", 1));
option(loc::gettext_case("Victoria", 1));
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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);
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("continue from teleporter"));
option(loc::gettext("continue from quicksave"));
option(loc::gettext("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::startnodeathmode:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("disable cutscenes"));
option(loc::gettext("enable cutscenes"));
option(loc::gettext("return"));
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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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:
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
option(loc::gettext("space station 1"), !unlock[Unlock_TIMETRIAL_SPACESTATION1]);
option(loc::gettext("the laboratory"), !unlock[Unlock_TIMETRIAL_LABORATORY]);
option(loc::gettext("the tower"), !unlock[Unlock_TIMETRIAL_TOWER]);
option(loc::gettext("space station 2"), !unlock[Unlock_TIMETRIAL_SPACESTATION2]);
option(loc::gettext("the warp zone"), !unlock[Unlock_TIMETRIAL_WARPZONE]);
option(loc::gettext("the final level"), !unlock[Unlock_TIMETRIAL_FINALLEVEL]);
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("return"));
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:
Use enums for unlock, unlocknotify, unlocknum This adds an anonymous enum for the unlock and unlocknotify arrays and unlocknum function, and replaces all integer literals with them. This is not named and thus cannot be used for strict typechecking because these are actually indexes into an array in XML save files, so the numbers themselves matter a lot.
2023-06-06 02:34:27 +02:00
option(loc::gettext(unlock[Unlock_TIMETRIAL_SPACESTATION1] ? "space station 1" : "???"),
unlock[Unlock_TIMETRIAL_SPACESTATION1]);
option(loc::gettext(unlock[Unlock_TIMETRIAL_LABORATORY] ? "the laboratory" : "???"),
unlock[Unlock_TIMETRIAL_LABORATORY]);
option(loc::gettext(unlock[Unlock_TIMETRIAL_TOWER] ? "the tower" : "???"),
unlock[Unlock_TIMETRIAL_TOWER]);
option(loc::gettext(unlock[Unlock_TIMETRIAL_SPACESTATION2] ? "space station 2" : "???"),
unlock[Unlock_TIMETRIAL_SPACESTATION2]);
option(loc::gettext(unlock[Unlock_TIMETRIAL_WARPZONE] ? "the warp zone" : "???"),
unlock[Unlock_TIMETRIAL_WARPZONE]);
option(loc::gettext(unlock[Unlock_TIMETRIAL_FINALLEVEL] ? "the final level" : "???"),
unlock[Unlock_TIMETRIAL_FINALLEVEL]);
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("return"));
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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("return to play menu"));
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("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:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("ok"));
option(loc::gettext("silence"));
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
menuyoff = 10;
break;
Do not close game if custom level has assets issues It's quite rude to close the game entirely if there is trouble with assets. Instead, just unload the assets and gracefully return to the title screen.
2021-08-07 05:57:34 +02:00
case Menu::errorloadinglevel:
Display improper zip structure message to non-console users If a zip file is improperly structured, a message will be displayed when the player loads the level list. This will only display the last-displayed improper zip, because there only needs to be one displayed at a time. Also because doing anything more would most likely require heap allocation, and I don't want to do that.
2021-08-07 07:26:48 +02:00
case Menu::warninglevellist:
Game.cpp: make menu options (in Game::createmenu) translatable This mainly adds loc::gettext calls for menu option labels. This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 23:32:38 +01:00
option(loc::gettext("ok"));
Display improper zip structure message to non-console users If a zip file is improperly structured, a message will be displayed when the player loads the level list. This will only display the last-displayed improper zip, because there only needs to be one displayed at a time. Also because doing anything more would most likely require heap allocation, and I don't want to do that.
2021-08-07 07:26:48 +02:00
menuyoff = 50;
Do not close game if custom level has assets issues It's quite rude to close the game entirely if there is trouble with assets. Instead, just unload the assets and gracefully return to the title screen.
2021-08-07 05:57:34 +02:00
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++)
{
Migrate more prints and graphics.len calls to font:: I especially focused on graphics.len and the print calls around them, because graphics.len calls appear a bit less often, might be overlooked when migrating print calls (thus possibly using different fonts by accident) and are often used for some kind of right-alignment or centering which can be changed into PR_RIGHT or PR_CEN with a different X anyway. Notably, I also added a new function to generate these kinds of sliders: ....[]............ Different languages means that the slider for analogue stick sensitivity needs to be longer to fit possibly long words for Low/Medium/High, and then different font sizes means that the longer slider won't fit onscreen in a language that needs a 12-wide font. So slider_get() can take a "target width", which dynamically changes the number of characters depending on the width of them in the interface font. I kinda forgot that I could force the 8x8 font instead of adapting the characters in the slider to the font, and other ideas (like using different characters or a more graphical progress bar) have been brought up on Discord, so this might all change again sooner or later.
2023-01-16 21:29:50 +01:00
int width = i*menuspacing + font::len(menuoptions[i].print_flags, menuoptions[i].text);
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
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
{
Prevent deleting saves in special or customs This prevents deleting telesaves and quicksaves in special modes and custom levels. Otherwise, rolling credits in a custom level would still delete the main game quicksave.
2023-05-22 21:14:01 +02:00
if (inspecial() || map.custommode)
{
return;
}
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
if (!FILESYSTEM_delete("saves/qsave.vvv"))
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Error deleting saves/qsave.vvv");
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
}
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
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
{
SDL_zero(last_quicksave);
}
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
{
Prevent deleting saves in special or customs This prevents deleting telesaves and quicksaves in special modes and custom levels. Otherwise, rolling credits in a custom level would still delete the main game quicksave.
2023-05-22 21:14:01 +02:00
if (inspecial() || map.custommode)
{
return;
}
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
if (!FILESYSTEM_delete("saves/tsave.vvv"))
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Error deleting saves/tsave.vvv");
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
}
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
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
{
SDL_zero(last_telesave);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add being able to delete a custom level quicksave Custom level quicksaves are NOT affected by the clear data menu, so the player should be able to delete quicksaves this way. The quicksave confirmation menu now has an extra option to delete the save (and that option also has its own confirmation menu before deleting).
2021-08-12 05:26:58 +02:00
void Game::customdeletequick(const std::string& file)
{
const std::string path = "saves/" + file.substr(7) + ".vvv";
if (!FILESYSTEM_delete(path.c_str()))
{
Replace all print calls with vlog calls This is pretty straight-forward to do.
2021-02-24 00:21:29 +01:00
vlog_error("Error deleting %s", path.c_str());
Add being able to delete a custom level quicksave Custom level quicksaves are NOT affected by the clear data menu, so the player should be able to delete quicksaves this way. The quicksave confirmation menu now has an extra option to delete the save (and that option also has its own confirmation menu before deleting).
2021-08-12 05:26:58 +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::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
{
Replace std::string Game::telesummary and Game::quicksummary by Summary Game::telesummary and Game::quicksummary stored the summary string for the save files - which is the <summary> tag that says something like "Space Station, 10:30:59". The game only ever displays the quicksave variant of these two, for "Last Save:" on the map menu's SAVE tab. So the telesave has a <summary> too, but it's never displayed anywhere. (In fact, the area is often set to "nowhere"...) However, the summary strings have another function: detect that both the telesave and quicksave exist. If a summary string for a save is empty, then that save is considered not to exist. I'm refactoring the summary string system, by making the new variables Game::last_telesave and Game::last_quicksave of type struct Game::Summary. This struct should have all data necessary to display the summary string at runtime, and thus translate it at runtime (so we don't store a summary in a certain language and then display it in the wrong font later - the summary can always be in the current language). It also has an `exists` member, to replace the need to check for empty strings. The <summary> tag is now completely unused, but is still written to for older versions of the game to read. (This commit does not add the new string to the language files, since Terry now added it separately in his own branch)
2023-09-12 14:36:58 +02:00
return last_telesave.exists || last_quicksave.exists;
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
}
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
Defer hardreset to end of frame in quittomenu This fixes a bug where the wrong music can play on the title screen, as reported by AllyTally on Discord. The bug can be triggered by triggering a room transition right as game.quittomenu() is called (which is easiest to achieve by placing the player on an oscillating/"out of bounds" room border in a custom level so they go back and forth between two rooms every frame, and triggering gamestate 1013, which starts a fadeout to menu if all custom crewmates are rescued). When this happens, game.quittomenu() calls script.hardreset(), but the rest of the frame still executes, even though we set game.gamestate to TITLEMODE too (because game.quittomenu() was called by game.updatestate() which was called by gamelogic(), and game.gamestate is only checked at the start of the frame). This ends up triggering a room transition, and since map.custommode is guaranteed to now be off (because of script.hardreset()), the main game music area code kicks in, and plays something that isn't Presenting VVVVVV. The bug here is that we're resetting too early when we still have the rest of an in-game frame to execute. So, instead, we should only reset at the end of the frame, and this can be achieved with a defer callback.
2023-05-19 04:11:04 +02:00
static void hardreset(void)
{
script.hardreset();
}
Prevent other cases of losing unsaved levels by returning to menu 2.3 already made it so that if you ran the `rollcredits` command during in-editor playtesting, you wouldn't be returned to the title screen while losing unsaved level changes. But there are plenty of other ways to go back to the title screen from in-editor playtesting too. Namely, gamestate 1015 (the gamestate after completing a level) and 82 (time trial complete). So just add the appropriate checks to those gamestates, and add a catch-all check in Game::quittomenu(). Additionally, Game::updatecustomlevelstats() should not update custom level stats during in-editor playtesting (otherwise it would still happen even if the game didn't bring you back to the title screen). Editor notes will also be shown if the game prevents you from going to the title screen. Also, just to make things clear, I also added a level note for when the level is completed during in-editor playtesting. This is just to make it clear in cases where it might not be obvious that the game returned you to the editor for this reason. E.g. you have a terminal that calls gamestate(1013) in a level with 0 custom crewmates, but when you activate it, it looks like the terminal didn't work for some reason and just brought you back to the editor. But that's just only because you literally just completed the level.
2023-05-19 04:58:23 +02:00
static void returntoeditor_callback(void)
{
extern Game game;
game.returntoeditor();
ed.show_note(loc::gettext("Level quits to menu"));
}
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
{
Allow quitting to menu if gamestate is EDITORMODE Otherwise you wouldn't be able to quit from the editor normally.
2023-05-21 00:22:08 +02:00
if (gamestate != EDITORMODE && map.custommode && !map.custommodeforreal)
Prevent other cases of losing unsaved levels by returning to menu 2.3 already made it so that if you ran the `rollcredits` command during in-editor playtesting, you wouldn't be returned to the title screen while losing unsaved level changes. But there are plenty of other ways to go back to the title screen from in-editor playtesting too. Namely, gamestate 1015 (the gamestate after completing a level) and 82 (time trial complete). So just add the appropriate checks to those gamestates, and add a catch-all check in Game::quittomenu(). Additionally, Game::updatecustomlevelstats() should not update custom level stats during in-editor playtesting (otherwise it would still happen even if the game didn't bring you back to the title screen). Editor notes will also be shown if the game prevents you from going to the title screen. Also, just to make things clear, I also added a level note for when the level is completed during in-editor playtesting. This is just to make it clear in cases where it might not be obvious that the game returned you to the editor for this reason. E.g. you have a terminal that calls gamestate(1013) in a level with 0 custom crewmates, but when you activate it, it looks like the terminal didn't work for some reason and just brought you back to the editor. But that's just only because you literally just completed the level.
2023-05-19 04:58:23 +02:00
{
/* We are playtesting! Go back to the editor
* instead of losing unsaved changes. */
/* This needs to be deferred, otherwise some state would persist. */
DEFER_CALLBACK(returntoeditor_callback);
return;
}
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;
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEIN;
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();
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
loc::unloadtext_custom();
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
font::unload_custom();
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
Add cutscene test menu This allows translators to test all text boxes in the scripts. It doesn't run the scripts themselves - it only shows the basic appearance of each text box individually, so context may be lost but it's good to have a way to see any text boxes that might otherwise not be easily seen because they require specific circumstances to appear.
2022-12-24 04:16:56 +01:00
if (translator_cutscene_test)
{
returntomenu(Menu::translator_options_cutscenetest);
}
else if (translator_exploring)
Add level exploring menu for translators I would, of course, recommend translators to translate the roomnames while playing the full game (optionally in invincibility) so they can immediately get all the context and maybe the most inspiration. And if you want to go back into a specific level, then there's always the time trials and intermission replays which will give you full coverage of all the room names. However, the time trials weren't really made for room name translation. They have some annoying features like the instant restart when you press ENTER at the wrong time, they remove context clues like teleporters and companions, but the worst problem is that the last room in a level is often completely untranslatable inside the time trials because you immediately get sent to the results screen... So, I added a new menu in the translator options, "explore game", which gives you access to all the time trials and the two intermissions, from the same menu. All these time trials (which they're still based off of, under the hood) are stripped of the annoying features that come with time trials. These are the changes I made to time trial behavior in translator exploring mode: - No 3-2-1-Go! countdown - No on-screen time/death/shiny/par - ENTER doesn't restart, and the map menu works. The entire map is also revealed. - Prize for the Reckless is in its normal form - The teleporters in Entanglement Generator, Wheeler's Wormhole and Level Complete are restored as context for room names (actually, we should probably restore them in time trials anyway? Their "press to teleport" prompt is already blocked out in time trials and they do nothing other than being a checkpoint. I guess the reason they were removed was to stop people from opening the teleporter menu when that was not specifically blocked out in time trials yet.) - The companions are there at the end of levels, and behave like in no death mode (become happy and follow you to the teleporter). Also for context. - At the end of each level, you're not suddenly sent to the menu, but you can use the teleporter at your leisure just like in the intermission replays. In the Final Level, you do get sent to the menu automatically, but after a longer delay. I made another mark on VVVVVV: don't be startled, I added gamestates. I wanted all teleporters at the end of levels to behave like the ones at the end of the intermission replays, and all handling for teleporting with specific companions is already done in gamestates, so rather than adding conditional blocks across 5 or so different gamestates, it made more sense to make a single gamestate for "teleporting in translator exploring mode" (3090). I also added an alternative to having to use gamestate 3500 or 82 for the end of the final level: 3091-3092. One other thing I want to add to the "explore game" menu: a per-level count of how many room names are left to translate. That shouldn't be too difficult, and I'm planning that for the next commit.
2022-11-26 03:33:17 +01:00
{
returntomenu(Menu::translator_options_exploregame);
}
else 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
Update editor_disabled more often, remove `-enable-editor`
2023-08-25 03:15:04 +02:00
editor_disabled = !BUTTONGLYPHS_keyboard_is_available();
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
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);
}
Defer hardreset to end of frame in quittomenu This fixes a bug where the wrong music can play on the title screen, as reported by AllyTally on Discord. The bug can be triggered by triggering a room transition right as game.quittomenu() is called (which is easiest to achieve by placing the player on an oscillating/"out of bounds" room border in a custom level so they go back and forth between two rooms every frame, and triggering gamestate 1013, which starts a fadeout to menu if all custom crewmates are rescued). When this happens, game.quittomenu() calls script.hardreset(), but the rest of the frame still executes, even though we set game.gamestate to TITLEMODE too (because game.quittomenu() was called by game.updatestate() which was called by gamelogic(), and game.gamestate is only checked at the start of the frame). This ends up triggering a room transition, and since map.custommode is guaranteed to now be off (because of script.hardreset()), the main game music area code kicks in, and plays something that isn't Presenting VVVVVV. The bug here is that we're resetting too early when we still have the rest of an in-game frame to execute. So, instead, we should only reset at the end of the frame, and this can be achieved with a defer callback.
2023-05-19 04:11:04 +02:00
/* We might not be at the end of the frame yet.
* If we hardreset() now, some state might still persist. */
DEFER_CALLBACK(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;
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_START_FADEIN;
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;
}
Use enums for music tracks This adds an anonymous enum for music tracks and replaces all calls to music.play and music.niceplay that use integer literals. Additionally, this is also done for integer literals for cl.levmusic (except 0) and music.currentsong where appropriate, but _not_ the music areamap because that would not make it look very aesthetically pleasing in the code. This is not a named enum (that can be used for strict typechecking) because music track IDs are essentially part of the API of the game - almost every custom level uses these numbers. This is just to make the source code more readable without needing a comment to denote what number is what track.
2023-05-24 03:37:32 +02:00
music.play(Music_PIPEDREAM);
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
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
Rename `textbox` to `textboxes` and textbox `line` to `lines` It's really dumb that these array names aren't plural when they should be, because they contain more than one thing.
2021-09-13 06:02:15 +02:00
graphics.textboxes.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 locking
2022-12-07 00:20:48 +01:00
setstate(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;
Enumify all fade modes This removes the magic numbers previously used for controlling the fade mode, which are really not readable at all unless you already know what they mean. 0: FADE_NONE 1: FADE_FULLY_BLACK 2: FADE_START_FADEOUT 3: FADE_FADING_OUT 4: FADE_START_FADEIN 5: FADE_FADING_IN There is also the macro FADEMODE_IS_FADING, which indicates when the intention is to only check if the game is fading right now, which wasn't clearly conveyed previously. I also took the opportunity to clean up the style of any lines I touched. This included rewriting if-else chains into case-switches, turning one-liner if-then statements into proper blocks, fixing up comments, and even commenting the `fademode == FADE_NONE` on the tower spike checks (which, it was previously undocumented why that check was there, but I think I know why it's there). As for type safety, we already get some by transforming the variable types into the enum. Assignment is prohibited without a cast. But, apparently, comparison is perfectly legal and won't even give so much as a warning. To work around this and make absolutely sure I made all existing comparisons now use the enum, I temporarily changed it to be an `enum class`, which is a C++11 feature that makes it so all comparisons are illegal. Unfortunately, it scopes them in a namespace with the same name as a class, so I had to temporarily define macros to make sure my existing code worked. I also had to temporarily up the standard in CMakeLists.txt to get it to compile. But after all that was done, I found the rest of the places where a comparison to an integer was used, and fixed them.
2022-04-25 09:57:47 +02:00
graphics.fademode = FADE_NONE;
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
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;
Move everything to the editor state system This commit moves everything left out of the previous commit to the state system. This means a bunch of new functions were added as well, to avoid the code in each function becoming too huge. A lot of cleanup was done as well, simplifying logic, merging duplicated code, etc. This commit does NOT touch "script hooks", script editor logic and autotiling, as those seem to be their own separate beasts.
2023-03-05 19:59:36 +01:00
ed.old_note_timer = 0;
ed.note_timer = 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
Add setfont scripting command The <font> in the level file is basically the starting font, but it can be changed at any time via scripting.
2023-01-20 04:57:06 +01:00
// Might've been changed in a script
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
font::set_level_font(cl.level_font_name.c_str());
Add setfont scripting command The <font> in the level file is basically the starting font, but it can be changed at any time via scripting.
2023-01-20 04:57:06 +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
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!
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
for (int j = 0; j < cl.maxheight; j++)
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
{
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
for (int i = 0; i < cl.maxwidth; i++)
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
{
Rename cl.level to cl.roomproperties I mean, that's what they are. Room properties are within a level, not a level themselves. So...
2021-02-21 00:54:24 +01:00
cl.roomproperties[i+(j*cl.maxwidth)].warpdir=ed.kludgewarpdir[i+(j*cl.maxwidth)];
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
}
}
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;
Cleanup tools & main rendering Tools were a mess, spread all over the code with hundreds of `else-if` statements. Instead of magic numbers denoting tools, an enum has been created, and logic has been extracted into simple switch/cases, shared logic being deduplicated. The base of a state system for the editor has been created as well, laying a good path for further organization improvements. Because of this, the entire editor no longer gets drawn underneath the menus, except for a few pieces which I haven't extracted yet. Either way, this should be good for performance, if that was a concern.
2023-03-02 07:45:22 +01:00
graphics.backgrounddrawn = false;
graphics.foregrounddrawn = false;
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
}
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
static void returntoedsettings(void)
{
extern Game game;
game.returntomenu(Menu::ed_settings);
}
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;
Remove NO_EDITOR/NO_CUSTOM_LEVELS, disable editor on Steam Deck This commit removes the `NO_EDITOR` and `NO_CUSTOM_LEVELS` defines, which cleans up the code a lot, and they weren't really needed anyways. This commit also disables the editor on the Steam Deck, and adds a program argument to re-enable the editor, `-enable-editor`.
2023-08-23 19:51:11 +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
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
{
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);
Fix not-Flip-Mode flag turning off when returning from options menu We need to check for graphics.setflipmode, not graphics.flipmode, because graphics.flipmode only gets assigned at the end of the frame (due to the deferred callback). Otherwise, returning from the options menu would always turn flag 73 on, which would make you ineligible to get the Flip Mode trophy, even if you're in Flip Mode.
2021-09-01 00:33:20 +02:00
if (!map.custommode && !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
{
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
Add debug print to unlockAchievement This print is useful to know if an achievement (one that's not already unlocked) would actually be unlocked in an end user environment, while running the game in a dev environment. Also fixed up the style of the function because it was definitely inconsistent with the surrounding code.
2022-12-29 23:25:27 +01:00
void Game::unlockAchievement(const char* name)
{
Silence various warnings in builds removing content The MAKEANDPLAY, NO_CUSTOM_LEVELS, and NO_EDITOR defines remove content or features. However, they then raise several warnings because of some cases, functions, or variables that end up not being used. This silences them by using the UNUSED macro, or by adding a default catch-all case if the define is defined (so unhandled cases will still raise warnings in a build that doesn't have these defines).
2023-02-04 09:14:04 +01:00
#ifdef MAKEANDPLAY
UNUSED(name);
#else
Add debug print to unlockAchievement This print is useful to know if an achievement (one that's not already unlocked) would actually be unlocked in an end user environment, while running the game in a dev environment. Also fixed up the style of the function because it was definitely inconsistent with the surrounding code.
2022-12-29 23:25:27 +01:00
if (map.custommode)
{
return;
}
vlog_debug("Achievement \"%s\" unlocked.", name);
NETWORK_unlockAchievement(name);
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
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
Change all game-gamestates to use an enum type Currently, all game-gamestate variables are just ints. This is not particularly type-safe, in case the number of enums changes. To verify that all current uses of the game-gamestate variables actually use the enums, change them to be typed with the enum instead. (As an aside, we should probably rename this so that it can't be confused with Terry's state machine that has several different ways to exploit to warp you to the credits, but that's something to do later.)
2021-12-18 08:57:55 +01:00
void Game::mapmenuchange(const enum GameGamestate newgamestate, const bool user_initiated)
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
{
Use `resumegamemode` to track menu animation This fixes a bug where the player could bring up the map on the very first frame of a gamemode(game) animation. This is because the menu animation checked graphics.menuoffset, but graphics.menuoffset wouldn't have changed at that point because it only set graphics.resumegamemode. Instead, just check for graphics.resumegamemode directly. We also need to assign it to false whenever the map is closed so the player won't be prevented from using the map screen again.
2021-09-06 01:59:05 +02:00
if (user_initiated && graphics.resumegamemode)
Prevent user-initiated map menu changes during menu animations This makes it so it's not even possible to stay on the TELEPORTERMODE screen by opening the map while it's being brought down. It also makes it so the map animation is able to be canceled when being brought up just by opening the map and closing it. Fixes #833.
2021-09-02 21:21:46 +02:00
{
return;
}
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;
Recache textures when returning to ingame from map Fixes #977.
2023-08-23 17:42:28 +02:00
gameScreen.recacheTextures();
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;
}
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();
Translate hardest room at display time instead of at time of death The hardest room used to be stored as a room name in whatever language it was in when you last died enough times to break the record (before localization, that was always English). Even after localization became a thing we could get away with this since we only had a single font, but now we might have actual question marks appearing when the new font doesn't support characters from the old language. Therefore, this commit adds more info about the hardest room to save files - everything that is needed to know in order to do the translation at display time. These are hardestroom_x and hardestroom_y for the room coordinates, as well as hardestroom_specialname to mark special names, in addition to changing the stored room name back to English. I've also added hardestroom_finalstretch in case we later decide to drop the English name as a key and rely on just the coordinates (even though I think that change itself would be more complicated than any simplification it would accomplish, and I don't think it's necessary, but better to have it if we do need it later)
2023-09-04 15:27:29 +02:00
ndmresulthardestroom = loc::gettext_roomname(false, hardestroom_x, hardestroom_y, hardestroom.c_str(), hardestroom_specialname);
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_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 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
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
bool Game::physics_frozen(void)
{
Add level debugger screen The level debugger is toggleable in playtesting mode by pressing Y. You can toggle whether or not the game is paused inside of the debugger by pressing TAB. The debugger screen allows you to see entity and block properties, and allows you to move them around.
2023-07-02 04:02:25 +02:00
return roomname_translator::is_pausing() || level_debugger::is_pausing();
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
}
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
Use enums for swngame This replaces the swngame int variable with a named enum and enforces strict typechecking on it. Strict typechecking is okay here as the swngame variable is not part of the API surface of the game in any way and is completely internal. And just to make things clear, I've added a SWN_NONE enum to use for initialization, because previously it was being initialized to 0, even though 0 was the Gravitron.
2023-06-05 08:24:31 +02:00
&& (swngame == SWN_SUPERGRAVITRON ||
swngame == SWN_START_SUPERGRAVITRON_STEP_1 ||
swngame == SWN_START_SUPERGRAVITRON_STEP_2)
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
)
|| 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;
}
Add in-game timer option (#790)
2021-08-05 23:31:20 +02:00
Add localization "foundation" (many code changes) This commit adds most of the code changes necessary for making the game translatable, but does not yet "unhardcode" nearly all of the strings (except in a few cases where it was hard to separate added loc::gettexts from foundational code changes, or all the localization- related menus which were also added by this commit.) This commit is part of rewritten history of the localization branch. The original (unsquashed) commit history can be found here: https://github.com/Dav999-v/VVVVVV/tree/localization-orig
2022-12-30 22:57:24 +01:00
bool Game::nocompetitive_unless_translator(void)
{
return slowdown < 30 || (map.invincibility && !roomname_translator::enabled);
}
void Game::sabotage_time_trial(void)
{
timetrialcheater = true;
hours++;
deathcounts += 100;
timetrialparlost = true;
}
Style: Fixup instances of `void` arguments The style we have here is that functions with no arguments are to have explicit `void` arguments, even though this doesn't apply in C++, because it does apply in C. Unfortunately, some have slipped through the cracks. This commit fixes them.
2023-03-18 23:24:14 +01:00
bool Game::isingamecompletescreen(void)
Add in-game timer option (#790)
2021-08-05 23:31:20 +02:00
{
return (state >= 3501 && state <= 3518) || (state >= 3520 && state <= 3522);
}
Reference in a new issue Copy permalink