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

142 lines
3.2 KiB
C
Raw Normal View History

Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#ifndef SCRIPT_H
#define SCRIPT_H
Remove hardcoded textbox colours We have a custom textbox colour system, why not use it? This also moves the map of colours from CustomLevels to Script.
2023-03-18 22:48:20 +01:00
#include <map>
Initial implementation of textbox sprites This commit adds a system for displaying sprites in textboxes, meant to replace the hardcoded system in the main game. This does not support levelcomplete.png and gamecomplete.png yet, which will most likely just be special cases.
2023-08-06 00:34:15 +02:00
#include <SDL.h>
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include <string>
#include <vector>
Initial implementation of textbox sprites This commit adds a system for displaying sprites in textboxes, meant to replace the hardcoded system in the main game. This does not support levelcomplete.png and gamecomplete.png yet, which will most likely just be special cases.
2023-08-06 00:34:15 +02:00
#include "Textbox.h"
Use SDL_arraysize() instead of writing out array length Using the macro makes it less likely that there will be a mistake when writing out the array length.
2020-09-10 06:48:45 +02:00
#define filllines(lines) commands.insert(commands.end(), lines, lines + SDL_arraysize(lines))
Refactor Scripts.cpp to no longer hold strings in function args Instead each line is now held in a const char* array, like it should be. This results in less work for the compiler, especially with optimization, since every time the compiler encounters a constant argument in a function, it has to go off and locate a place to put it. But if we're upfront and say, hey, here's all the strings we ever need conveniently packaged into one place, it'll be much more cooperative.
2020-05-18 19:37: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
#ifdef SCRIPT_DEFINITION
#define TEXT_COLOUR(a) textbox_colours[a]
#else
Remove hardcoded textbox colours We have a custom textbox colour system, why not use it? This also moves the map of colours from CustomLevels to Script.
2023-03-18 22:48:20 +01:00
#define TEXT_COLOUR(a) script.textbox_colours[a]
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
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Refactor custom scripts to not be stored in one giant vector of lines This commit refactors custom level scripts to no longer be stored in one giant vector containing not only every single script name, but every single script's contents as well. More specifically, scriptclass::customscript has been converted to an std::vector<Script> scriptclass::customscripts (note the extra S), and a Script is just a struct with an std::string name and std::vector<std::string> contents. This is an improvement in both performance and maintainability. The game no longer has to look through script contents in case they're actually script names, and then manually extract the script contents from there. Instead, all it has to do is look for script names only. And the contents are provided for free. This results in a performance gain. Also, the old system resulted in lots of boilerplate everywhere anytime scripts had to be handled or parsed. Now, the boilerplate is only done when saving or loading a custom level. This makes code quality much, much better. To be sure I didn't actually change anything, I tested by first saving Dimension Open in current 2.3 (because current 2.3 gets rid of the awful edentity whitespace), and then resaved it on this patch. There is absolutely no difference between the current-2.3-resave and this-patch-resave.
2020-06-12 02:31:57 +02:00
struct Script
{
std::string name;
std::vector<std::string> contents;
};
createentity command: Actually have p1/p2/p3/p4 defaults Since createentity() started accepting p1/p2/p3/p4 arguments, it now unconditionally passes in whatever arguments were present there previously, when there weren't any before. This can lead to unexpected behavior when selectively using and then omitting p1/p2/p3/p4 arguments. Also, plenty of existing levels already only use the 5-argument version of createentity(). And createcrewman() can take up to 6 arguments at once. It's not far-fetched that an existing level could createentity() right after doing a 6-argument createcrewman(), which would lead to a different behavior than in 2.2 and previous. So instead, instead of checking if `words[index]` is an empty string (it only sets the string to be empty if there are enough argument separators on the line), ACTUALLY check if it's empty. I've added a static array (no need for it to be exported) that keeps track of this. createentity() now checks for that instead of `words`.
2021-08-12 04:32:36 +02:00
#define NUM_SCRIPT_ARGS 40
Refactor scriptclass::startgamemode This overhauls scriptclass::gamemode massively. The first change is that it now uses an enum, and enforces using that enum via using its type instead of an int. This is because whenever you're reading any calls to startgamemode, you have no idea what magic number actually corresponds to what unless you read startgamemode itself. And when you do read it, not every case is commented adequately, so you'd have to do more work to figure out what each case is. With the enum, it's obvious and self-evident, and that also removes the need for all the comments in the function too. Some math is still done on mode variables (to simplify time trial code), but it's okay, we can just cast between int and the enum as needed. The second is that common code is now de-duplicated. There was a lot of code that every case does, such as calling hardreset, setting Flip Mode, resetting the player, calling gotoroom and so on. Now some code may be duplicated between cases, so I've tried to group up similar cases where possible (most notable example is grouping up the main game and No Death Mode cases together). But some code still might be duplicated in the end. Which is okay - I could've tried to de-duplicate it further but that just results in logic relevant to a specific case that's located far from the actual case itself. It's much better to leave things like setting fademode or loading scripts in the case itself. This also fixes a bug since 2.3 where playing No Death Mode (and never opening and closing the options menu) and beating it would also give you the Flip Mode trophy, since turning on the flag to invalidate Flip Mode in startgamemode only happened for the main game cases and in previous versions the game relied upon this flag being set when using a teleporter for some reason (which I removed in 2.3). Now instead of specifying it per case, I just do a !map.custommode check instead so it covers every single case at once.
2022-12-29 23:01:36 +01:00
enum StartMode
{
Start_MAINGAME,
Start_MAINGAME_TELESAVE,
Start_MAINGAME_QUICKSAVE,
Start_TIMETRIAL_SPACESTATION1,
Start_TIMETRIAL_LABORATORY,
Start_TIMETRIAL_TOWER,
Start_TIMETRIAL_SPACESTATION2,
Start_TIMETRIAL_WARPZONE,
Start_TIMETRIAL_FINALLEVEL,
Start_NODEATHMODE_WITHCUTSCENES,
Start_NODEATHMODE_NOCUTSCENES,
Start_SECRETLAB,
Start_INTERMISSION1_VITELLARY,
Start_INTERMISSION1_VERMILION,
Start_INTERMISSION1_VERDIGRIS,
Start_INTERMISSION1_VICTORIA,
Start_INTERMISSION2_VITELLARY,
Start_INTERMISSION2_VERMILION,
Start_INTERMISSION2_VERDIGRIS,
Start_INTERMISSION2_VICTORIA,
Start_EDITOR,
Start_EDITORPLAYTESTING,
Start_CUSTOM,
Start_CUSTOM_QUICKSAVE,
Start_QUIT,
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
Start_CUTSCENETEST,
Refactor scriptclass::startgamemode This overhauls scriptclass::gamemode massively. The first change is that it now uses an enum, and enforces using that enum via using its type instead of an int. This is because whenever you're reading any calls to startgamemode, you have no idea what magic number actually corresponds to what unless you read startgamemode itself. And when you do read it, not every case is commented adequately, so you'd have to do more work to figure out what each case is. With the enum, it's obvious and self-evident, and that also removes the need for all the comments in the function too. Some math is still done on mode variables (to simplify time trial code), but it's okay, we can just cast between int and the enum as needed. The second is that common code is now de-duplicated. There was a lot of code that every case does, such as calling hardreset, setting Flip Mode, resetting the player, calling gotoroom and so on. Now some code may be duplicated between cases, so I've tried to group up similar cases where possible (most notable example is grouping up the main game and No Death Mode cases together). But some code still might be duplicated in the end. Which is okay - I could've tried to de-duplicate it further but that just results in logic relevant to a specific case that's located far from the actual case itself. It's much better to leave things like setting fademode or loading scripts in the case itself. This also fixes a bug since 2.3 where playing No Death Mode (and never opening and closing the options menu) and beating it would also give you the Flip Mode trophy, since turning on the flag to invalidate Flip Mode in startgamemode only happened for the main game cases and in previous versions the game relied upon this flag being set when using a teleporter for some reason (which I removed in 2.3). Now instead of specifying it per case, I just do a !map.custommode check instead so it covers every single case at once.
2022-12-29 23:01:36 +01:00
Start_FIRST_NODEATHMODE = Start_NODEATHMODE_WITHCUTSCENES,
Start_LAST_NODEATHMODE = Start_NODEATHMODE_NOCUTSCENES,
Start_FIRST_INTERMISSION1 = Start_INTERMISSION1_VITELLARY,
Start_LAST_INTERMISSION1 = Start_INTERMISSION1_VICTORIA,
Start_FIRST_INTERMISSION2 = Start_INTERMISSION2_VITELLARY,
Start_LAST_INTERMISSION2 = Start_INTERMISSION2_VICTORIA,
Start_FIRST_TIMETRIAL = Start_TIMETRIAL_SPACESTATION1
};
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
class scriptclass
{
public:
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
scriptclass(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Prioritize loading processed script names This makes it so that whenever the game loads a script as directed by a script command, it will first try to load the script from the processed argument, and if that fails only then will it try to load the script from the raw argument. This fixes a regression reported by Dav999 in the custom level "Vungeon" created by Dynaboom, where a script `ifflag`s to `aselectP1.1` even though the actual script name is `aselectp1.1`. In 2.3, it would lowercase `aselectP1.1` and load the script properly, but previous to this commit it would try to load the script with a capital name and then fail.
2023-02-01 05:04:18 +01:00
bool load(const std::string& name);
Make scriptclass::load(other) rely less on std::string Instead of comparing against an std::string (which is heavily templated), just use good ol' SDL_strcmp().
2020-07-05 00:59:21 +02:00
void loadother(const char* t);
Prioritize loading processed script names This makes it so that whenever the game loads a script as directed by a script command, it will first try to load the script from the processed argument, and if that fails only then will it try to load the script from the raw argument. This fixes a regression reported by Dav999 in the custom level "Vungeon" created by Dynaboom, where a script `ifflag`s to `aselectP1.1` even though the actual script name is `aselectp1.1`. In 2.3, it would lowercase `aselectP1.1` and load the script properly, but previous to this commit it would try to load the script with a capital name and then fail.
2023-02-01 05:04:18 +01:00
bool loadcustom(const std::string& t);
void loadalts(const std::string& processed, const std::string& raw);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Make Violet's button dialogue work in cutscene test This was easier than I expected - just add an optional buttons="1" attribute to cutscenes.xml. It's treated like the speaker attribute - it's only there as context for the translator, and for the cutscene test.
2023-03-22 21:30:42 +01:00
void add_test_line(const std::string& speaker, const std::string& english, char textcase, bool textbuttons);
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
void loadtest(const std::string& name);
Make std::string-using script funcs pass around const references This makes it so that whenever a string is passed into these functions, it's no longer needlessly copied.
2020-07-05 01:01:35 +02:00
void inline add(const std::string& t)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Make `commands`, `sb`, and `hooklist` not use separate length-trackers This is a refactor that turns the script-related arrays `ed.sb`, and `ed.hooklist` into C++ vectors (`script.commands` was already a vector, it was just misused). The code handling these vectors now looks more like idiomatic C++ than sloppily-pasted pseudo-ActionScript. This removes the variables `script.scriptlength`, `ed.sblength`, and `ed.numhooks`, too. This reduces the amount of code needed to e.g. simply remove something from any of these vectors. Previously the code had to manually shift the rest of the elements down one-by-one, and doing it manually is definitely error-prone and tedious. But now we can just use fancy functions like `std::vector::erase()` and `std::remove()` to do it all in one line! Don't worry, I checked and `std::remove()` is in the C++ standard since at least 1998. This patch makes it so the `commands` vector gets cleared when `scriptclass::load()` is ran. Previously, the `commands` vector never actually properly got cleared, so there could potentially be glitches that rely on the game indexing past the bounds set by `scriptlength` but still in-bounds in the eyes of C++, and people could potentially rely on such an exploit... However, I checked, and I'm pretty sure that no such glitch previously existed at all, because the only times the vector gets indexed are when `scriptlength` is either being incremented after starting from 0 (`add()`) or when it's underneath a `position < scriptlength` conditional. Furthermore, I'm unaware of anyone who has actually found or used such an exploit, and I've been in the custom level community for 6 years. So I think it's fine.
2020-02-20 18:43:52 +01:00
commands.push_back(t);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Remove hardcoded textbox colours We have a custom textbox colour system, why not use it? This also moves the map of colours from CustomLevels to Script.
2023-03-18 22:48:20 +01:00
void add_default_colours(void);
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 clearcustom(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Make std::string-using script funcs pass around const references This makes it so that whenever a string is passed into these functions, it's no longer needlessly copied.
2020-07-05 01:01:35 +02:00
void tokenize(const std::string& t);
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 run(void);
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
void translate_dialogue(void);
Refactor scriptclass::startgamemode This overhauls scriptclass::gamemode massively. The first change is that it now uses an enum, and enforces using that enum via using its type instead of an int. This is because whenever you're reading any calls to startgamemode, you have no idea what magic number actually corresponds to what unless you read startgamemode itself. And when you do read it, not every case is commented adequately, so you'd have to do more work to figure out what each case is. With the enum, it's obvious and self-evident, and that also removes the need for all the comments in the function too. Some math is still done on mode variables (to simplify time trial code), but it's okay, we can just cast between int and the enum as needed. The second is that common code is now de-duplicated. There was a lot of code that every case does, such as calling hardreset, setting Flip Mode, resetting the player, calling gotoroom and so on. Now some code may be duplicated between cases, so I've tried to group up similar cases where possible (most notable example is grouping up the main game and No Death Mode cases together). But some code still might be duplicated in the end. Which is okay - I could've tried to de-duplicate it further but that just results in logic relevant to a specific case that's located far from the actual case itself. It's much better to leave things like setting fademode or loading scripts in the case itself. This also fixes a bug since 2.3 where playing No Death Mode (and never opening and closing the options menu) and beating it would also give you the Flip Mode trophy, since turning on the flag to invalidate Flip Mode in startgamemode only happened for the main game cases and in previous versions the game relied upon this flag being set when using a teleporter for some reason (which I removed in 2.3). Now instead of specifying it per case, I just do a !map.custommode check instead so it covers every single case at once.
2022-12-29 23:01:36 +01:00
void startgamemode(enum StartMode mode);
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 teleport(void);
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 hardreset(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Script contents
std::vector<std::string> commands;
createentity command: Actually have p1/p2/p3/p4 defaults Since createentity() started accepting p1/p2/p3/p4 arguments, it now unconditionally passes in whatever arguments were present there previously, when there weren't any before. This can lead to unexpected behavior when selectively using and then omitting p1/p2/p3/p4 arguments. Also, plenty of existing levels already only use the 5-argument version of createentity(). And createcrewman() can take up to 6 arguments at once. It's not far-fetched that an existing level could createentity() right after doing a 6-argument createcrewman(), which would lead to a different behavior than in 2.2 and previous. So instead, instead of checking if `words[index]` is an empty string (it only sets the string to be empty if there are enough argument separators on the line), ACTUALLY check if it's empty. I've added a static array (no need for it to be exported) that keeps track of this. createentity() now checks for that instead of `words`.
2021-08-12 04:32:36 +02:00
std::string words[NUM_SCRIPT_ARGS];
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::vector<std::string> txt;
std::string scriptname;
Make `commands`, `sb`, and `hooklist` not use separate length-trackers This is a refactor that turns the script-related arrays `ed.sb`, and `ed.hooklist` into C++ vectors (`script.commands` was already a vector, it was just misused). The code handling these vectors now looks more like idiomatic C++ than sloppily-pasted pseudo-ActionScript. This removes the variables `script.scriptlength`, `ed.sblength`, and `ed.numhooks`, too. This reduces the amount of code needed to e.g. simply remove something from any of these vectors. Previously the code had to manually shift the rest of the elements down one-by-one, and doing it manually is definitely error-prone and tedious. But now we can just use fancy functions like `std::vector::erase()` and `std::remove()` to do it all in one line! Don't worry, I checked and `std::remove()` is in the C++ standard since at least 1998. This patch makes it so the `commands` vector gets cleared when `scriptclass::load()` is ran. Previously, the `commands` vector never actually properly got cleared, so there could potentially be glitches that rely on the game indexing past the bounds set by `scriptlength` but still in-bounds in the eyes of C++, and people could potentially rely on such an exploit... However, I checked, and I'm pretty sure that no such glitch previously existed at all, because the only times the vector gets indexed are when `scriptlength` is either being incremented after starting from 0 (`add()`) or when it's underneath a `position < scriptlength` conditional. Furthermore, I'm unaware of anyone who has actually found or used such an exploit, and I've been in the custom level community for 6 years. So I think it's fine.
2020-02-20 18:43:52 +01:00
int position;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int looppoint, loopcount;
int scriptdelay;
Remove script.dontrunnextframe kludge Now that the game loop order is fixed, this kludge (on top of kludge) is no longer needed, and can be safely removed.
2020-11-08 01:49:32 +01:00
bool running;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove hardcoded textbox colours We have a custom textbox colour system, why not use it? This also moves the map of colours from CustomLevels to Script.
2023-03-18 22:48:20 +01:00
// Textbox stuff
std::map<std::string, SDL_Color> textbox_colours;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int textx;
int texty;
int r,g,b;
Switch flipme script command to use flipme textbox attribute This is why the text box attribute was named flipme, after all. You may have noticed that the flipme command inverts textflipme instead of simply setting it to true. Well, that's because it should be the same as the previous behavior, which was essentially to invert it instead of setting it to true - i.e. calling flipme twice would keep the original text box position in Flip Mode, which means it would be upside-down (this is a lot of flipping to keep track of...) - because flipme added to texty in-place instead of simply assigning to it. (It did the calculation incorrectly in 2.2 and previous, but I digress.) Similarly, textflipme is not reset in hardreset(), because none of the other script text box variables are reset either.
2021-03-20 04:08:41 +01:00
bool textflipme;
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 textcentertext;
size_t textpad_left;
size_t textpad_right;
size_t textpadtowidth;
char textcase;
Add textbuttons() script command, make Violet's ENTER dialogue dynamic Violet's dialogue now looks like this: squeak(purple) text(purple,0,0,2) Remember that you can press {b_map} to check where you are on the map! position(purple,above) textbuttons() speak_active The new textbuttons() command sets the next textbox to replace {b_map} with the map button, and {b_int} with the interact button. The remaining keys would be added as soon as they need to be added to ActionSets.h as well.
2023-03-18 22:31:13 +01:00
bool textbuttons;
Allow a maximum of 26 lines, with L suffix
2022-11-30 18:56:44 +01:00
bool textlarge;
Add textboxtimer command
2023-04-20 14:53:30 +02:00
int textboxtimer;
Initial implementation of textbox sprites This commit adds a system for displaying sprites in textboxes, meant to replace the hardcoded system in the main game. This does not support levelcomplete.png and gamecomplete.png yet, which will most likely just be special cases.
2023-08-06 00:34:15 +02:00
std::vector<TextboxSprite> textbox_sprites;
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
TextboxImage textbox_image;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Misc
int i, j, k;
//Custom level stuff
Refactor custom scripts to not be stored in one giant vector of lines This commit refactors custom level scripts to no longer be stored in one giant vector containing not only every single script name, but every single script's contents as well. More specifically, scriptclass::customscript has been converted to an std::vector<Script> scriptclass::customscripts (note the extra S), and a Script is just a struct with an std::string name and std::vector<std::string> contents. This is an improvement in both performance and maintainability. The game no longer has to look through script contents in case they're actually script names, and then manually extract the script contents from there. Instead, all it has to do is look for script names only. And the contents are provided for free. This results in a performance gain. Also, the old system resulted in lots of boilerplate everywhere anytime scripts had to be handled or parsed. Now, the boilerplate is only done when saving or loading a custom level. This makes code quality much, much better. To be sure I didn't actually change anything, I tested by first saving Dimension Open in current 2.3 (because current 2.3 gets rid of the awful edentity whitespace), and then resaved it on this patch. There is absolutely no difference between the current-2.3-resave and this-patch-resave.
2020-06-12 02:31:57 +02:00
std::vector<Script> customscripts;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01: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
#ifndef SCRIPT_DEFINITION
Clean up all scriptclass externs into one location I have the feeling that none of the devs understood what extern did, and they kind of just sprinkled it everywhere until things started working. But like all other classes, it should just be one line in the class's respective header file, and shouldn't be so messy.
2020-05-18 19:12:11 +02:00
extern scriptclass script;
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
#endif
Clean up all scriptclass externs into one location I have the feeling that none of the devs understood what extern did, and they kind of just sprinkled it everywhere until things started working. But like all other classes, it should just be one line in the class's respective header file, and shouldn't be so messy.
2020-05-18 19:12:11 +02:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#endif /* SCRIPT_H */
Reference in a new issue Copy permalink