mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-11-16 16:09:42 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/Map.h

203 lines
4 KiB
C
Raw Normal View History

Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#ifndef MAPGAME_H
#define MAPGAME_H
#include <vector>
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
#include <string>
Remove unnecessary includes from header files Including a header file inside another header file means a bunch of files are going to be unnecessarily recompiled whenever that inner header file is changed. So I minimized the amount of header files included in a header file, and only included the ones that were necessary (system includes don't count, I'm only talking about includes from within this project). Then the includes are only in the .cpp files themselves. This also minimizes problems such as a NO_CUSTOM_LEVELS build failing because some file depended on an include that got included in editor.h, which is another benefit of removing unnecessary includes from header files.
2020-07-19 21:05:41 +02:00
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 "Finalclass.h"
#include "Labclass.h"
#include "Otherlevel.h"
#include "Spacestation2.h"
#include "Tower.h"
Refactor tower background to use a separate object instead Previously, the tower background was controlled by a disparate set of attributes on Graphics and mapclass, and wasn't really encapsulated. (If that's what that word means, I don't particularly care about object-oriented lingo.) But now, all relevant things that a tower background has has been put into a TowerBG struct, so it will be easy to make multiple copies without having to duplicate the code that handles it.
2020-11-03 00:05:24 +01:00
#include "TowerBG.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 "WarpClass.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Move Roomtext struct to Map.h This is a more appropriate place for it, because it's never used in Otherlevel.cpp.
2020-07-06 21:37:04 +02:00
struct Roomtext
{
int x, y;
Replace roomnames/hiddennames/glitchnames with `const char*` Since those are all downstream recipients of either static storage or memory that doesn't move for the duration of the custom level, it's okay to make these be `const char*`s without having to redo any of the RAII memory management. mapclass::currentarea() is included in this as well. I also cleaned up Tower.cpp's headers to fix some transitive includes because I was removing UtilityClass.h includes from all other level files too. The "Untitled room" names no longer show any coordinates, because doing so would require complicated memory management that's completely unneeded. No one will ever see them, and if they do they already know they have a problem anyway. The only time they might be able to see them is if they corrupted the areamap, but this was only possible in 2.2 and previous by dying outside the room deaths array in Outside Dimension VVVVVV, which has since been patched out. Besides, sometimes the "Untitled room" gets overwritten by something else anyway (especially in Finalclass.cpp), so it really, really doesn't matter.
2021-09-12 21:48:15 +02:00
const char* text;
Move Roomtext struct to Map.h This is a more appropriate place for it, because it's never used in Otherlevel.cpp.
2020-07-06 21:37:04 +02:00
};
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
enum RoomnameType
{
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
RoomnameType_STATIC,
RoomnameType_GLITCH,
RoomnameType_TRANSFORM
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
};
struct Roomname
{
int x;
int y;
bool loop;
int flag;
RoomnameType type;
std::vector<std::string> text;
int progress;
int delay;
};
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
class mapclass
{
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
mapclass(void);
Make room names own their own memory This makes it so room names are no longer pointers to someone else's memory, and instead to set them you use `mapclass::setroomname`. If the string is short enough to fit in a static, no-alloc buffer, then it gets copied there. Otherwise, a new heap allocation is made that duplicates the string, and the new pointer is used instead. This makes it possible for room names to contain arbitrary data whose origin is temporary (e.g. from a script command that could be added in the future).
2022-12-01 07:35:42 +01:00
void destroy(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unify all queries to map size to `map.getwidth` and `map.getheight` It's becoming pretty clear that the size of the map is important enough to be queried a lot, but each time it's something like `map.custommode ? map.customwidth : 20` and `map.custommode ? map.customheight : 20` which is not ideal because of copy-pasting. Furthermore, even `map.customwidth` and `map.customheight` are just duplicates of `cl.mapwidth` and `cl.mapheight`, which are only set in `customlevelclass::generatecustomminimap`. This is a bit annoying if you want to, say, add checks that depend on the width and height of the custom map in `mapclass::initcustommapdata`, but `map.customwidth` and `map.customheight` are out of date because `generatecustomminimap` hasn't been called yet. And doing the ternary there requires a `#ifndef NO_CUSTOM_LEVELS` to reference `cl.mapwidth` and `cl.mapheight` which is just awful. So I'm axing `map.customwidth` and `map.customheight`, and I'm axing all the ternaries that are duplicating the source of truth in `MapRenderData`. Instead, there will just be one function to call for the width and height, `mapclass::getwidth` and `mapclass::getheight`, and everyone can simply call those without needing to do ternaries or duplication.
2022-11-30 22:35:14 +01:00
int getwidth(void);
int getheight(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int intpol(int a, int b, float c);
Remove now-unused parameter 't' from mapclass::setteleporter() This was previously used to set the indice of the teleporter, but now that we do push_back() it's no longer necessary and is now unused.
2020-04-15 04:29:19 +02:00
void setteleporter(int x, int y);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove now-unused parameter 't' from mapclass::settrinket() This parameter used to be used to set the trinket based on indice, but now that we push_back it's no longer used.
2020-04-15 04:37:00 +02:00
void settrinket(int x, int y);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Make room names own their own memory This makes it so room names are no longer pointers to someone else's memory, and instead to set them you use `mapclass::setroomname`. If the string is short enough to fit in a static, no-alloc buffer, then it gets copied there. Otherwise, a new heap allocation is made that duplicates the string, and the new pointer is used instead. This makes it possible for room names to contain arbitrary data whose origin is temporary (e.g. from a script command that could be added in the future).
2022-12-01 07:35:42 +01:00
void setroomname(const char* 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 resetmap(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
void updateroomnames(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 initmapdata(void);
void initcustommapdata(void);
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
void roomnamechange(int x, int y, const char** lines, size_t size);
void roomnameglitch(int x, int y, const char* name, const char* glitch);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int finalat(int x, int y);
int maptiletoenemycol(int t);
Remove global args from mapclass This commit removes the global args being passed around from the function args on the mapclass object, as well as updating all callers in other files to not have those args. Furthermore, 'dwgfx' has been renamed to 'graphics' in Map.cpp.
2020-03-31 10:09:42 +02:00
void changefinalcol(int t);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Move mapclass r/g/b variables off onto TowerBG This fixes a bug where if you entered a tower before watching the credits sequence, the credits sequence would have mismatched text and background colors. This bug happened because entering a tower modified the r/g/b attributes of mapclass, and updated graphics.towerbg, without updating graphics.titlebg too. Then gamecompleterender() uses the r/g/b attributes of mapclass. The solution is to put the r/g/b attributes on TowerBG instead. That way, entering a tower will only modify the r/g/b attributes used to render towers, and won't affect the r/g/b attributes used to render the credits sequence. Additionally, I also de-duplicated the case-switch that updated the r/g/b attributes based off of the current colstate, because it got copy-pasted twice, leading to three instances of one piece of code.
2021-01-08 02:37:38 +01:00
void setcol(TowerBG& bg_obj, const int r1, const int g1, const int b1 , const int r2, const int g2, const int b2, const int c);
void updatebgobj(TowerBG& bg_obj);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Consolidate tower BG bypos and bscroll assignments Tower backgrounds have a bypos and bscroll. bypos is just the y-position of the background, and bscroll is the amount of pixels to scroll the background by on each frame, which is used to scroll it (if it's not being redrawn) and for linear interpolation. For the tower background (and not the title background), bypos is map.ypos / 2, and bscroll is (map.ypos - map.oldypos) / 2. However, usually bscroll gets assigned at the same time bypos is incremented or decremented, so you never see that calculation explicitly - except in the previous commit, where I worked out the calculation because the change in y-position isn't a known constant. Having to do all these calculations every time introduces the possibility of errors where you forget to do it, or you do it wrongly. But that's not even the worst; you could cause a linear interpolation glitch if you decide to overwrite bscroll without taking into account map.oldypos and map.ypos. So that's why I'm adding a function that automatically updates the tower background, using the values of map.oldypos and map.ypos, that is used every time map.ypos is assigned. That way, we have to write less code, you can be sure that there's no place where we forget to do the calculations (or at least it will be glaringly obvious) or we do it wrongly, and it plays nicely with linear interpolation. This also replaces every instance where the manual calculations are done with the new function.
2021-04-23 03:47:07 +02:00
void setbgobjlerp(TowerBG& bg_obj);
Refactor tower background to use a separate object instead Previously, the tower background was controlled by a disparate set of attributes on Graphics and mapclass, and wasn't really encapsulated. (If that's what that word means, I don't particularly care about object-oriented lingo.) But now, all relevant things that a tower background has has been put into a TowerBG struct, so it will be easy to make multiple copies without having to duplicate the code that handles it.
2020-11-03 00:05:24 +01:00
void updatetowerglow(TowerBG& bg_obj);
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 nexttowercolour(void);
Fix cycling title BG more than once per frame This can happen if you select an option in a menu that (A) returns to the previous menu and (B) saves settings. If the settings save fails, this will create another menu on the same frame that cycles the tower BG after it's already been cycled for that frame. Examples are the slowdown and glitchrunner menus. I could fix this by creating a new function that copy-pastes all of Game::savestatsandsettings_menu() except for the map.nexttowercolour() at the end. But that's copy-pasting code. Instead what I've done is added a variable to signal if the color has already been cycled this frame, so we don't cycle it again. This also covers cases of possible double-cycling in the future as well.
2021-08-06 01:38:06 +02:00
bool nexttowercolour_set;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void settowercolour(int t);
Don't treat spikes as solid for non-humanoid entities There's always been a bit of an inconsistency in the game where enabling invincibility would make spikes so solid that enemies and moving platforms would treat spikes as solid and bounces off of them. This fixes that by adding an `invincible` parameter to collision functions, so the functions will only treat spikes as solid if that parameter is true, and the parameter passed will only be true if it's called for an entity that is a humanoid and invincibility mode is enabled. Also, for clarity, `spikecollide` is renamed to `towerspikecollide` because it's only used for tower spikes. And as a small optimization, `checktowerspikes` returns early if invincibility mode is enabled.
2022-06-06 05:17:26 +02:00
bool towerspikecollide(int x, int y);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't treat spikes as solid for non-humanoid entities There's always been a bit of an inconsistency in the game where enabling invincibility would make spikes so solid that enemies and moving platforms would treat spikes as solid and bounces off of them. This fixes that by adding an `invincible` parameter to collision functions, so the functions will only treat spikes as solid if that parameter is true, and the parameter passed will only be true if it's called for an entity that is a humanoid and invincibility mode is enabled. Also, for clarity, `spikecollide` is renamed to `towerspikecollide` because it's only used for tower spikes. And as a small optimization, `checktowerspikes` returns early if invincibility mode is enabled.
2022-06-06 05:17:26 +02:00
bool collide(int x, int y, bool invincible);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void settile(int xp, int yp, int t);
int area(int _rx, int _ry);
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 exploretower(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 hideship(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 showship(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Fix player being invisible upon loading into game again When I did #567, I didn't test it. And I should have tested it, because it made the player invisible. This is because map.resetplayer() also sets the invis attribute of the player to true as well, and I only undid it setting game.lifeseq to 10. So instead, I'll just add a flag to map.resetplayer() that by default doesn't set game.lifeseq or the player's invis attribute. And I tested it this time, and it works fine. I tested both respawning after death and exiting to the menu and loading in the game again.
2020-12-28 22:16:16 +01:00
void resetplayer(const bool player_died);
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 resetplayer(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove global args from mapclass This commit removes the global args being passed around from the function args on the mapclass object, as well as updating all callers in other files to not have those args. Furthermore, 'dwgfx' has been renamed to 'graphics' in Map.cpp.
2020-03-31 10:09:42 +02:00
void warpto(int rx, int ry , int t, int tx, int ty);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove global args from mapclass This commit removes the global args being passed around from the function args on the mapclass object, as well as updating all callers in other files to not have those args. Furthermore, 'dwgfx' has been renamed to 'graphics' in Map.cpp.
2020-03-31 10:09:42 +02:00
void gotoroom(int rx, int ry);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Fix regression with companions not spawning Companions would not spawn if you didn't load the current room via a room transition. This meant that companions wouldn't spawn if you loaded a save file with a companion, at least not until you moved to a different room and triggered a screen transition. But most importantly, it meant that the Intermission 1 supercrewmate would never spawn, because going to Intermission 1 does a straight gotoroom, and does not do a room transition. Turns out the roomchange refactor broke things, because of course it did. The companion logic was implicitly relying on that bool to be set, because...? Either way, it doesn't make sense. Using roomchange implied that the code wanted to be ran only when doing a room transition, which is clearly not the case here. The best thing to do here is to just move it to a separate function that gets called at the end of mapclass::gotoroom().
2021-09-12 07:53:07 +02:00
void spawncompanion(void);
Simplify mapclass::currentarea() It used to take a single int: the area number returned by mapclass::area(roomx, roomy). All uses of currentarea() were called with an extra area() call as its argument. Additionally, there's a good reason why currentarea() should have the room coordinates: in one of the cases that it's called, there's a special case for the ship's coordinates. This results in the SAVE screen in the map menu being able to show "The Ship", while the continue screen shows "Dimension VVVVVV" instead. Therefore, why not put that exception inside currentarea() instead, and remove a few callsite map.area() wrappers by making currentarea() take the room x and y coordinates?
2023-09-12 00:07:10 +02:00
const char* currentarea(int roomx, int roomy);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove global args from mapclass This commit removes the global args being passed around from the function args on the mapclass object, as well as updating all callers in other files to not have those args. Furthermore, 'dwgfx' has been renamed to 'graphics' in Map.cpp.
2020-03-31 10:09:42 +02:00
void loadlevel(int rx, int ry);
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 twoframedelayfix(void);
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
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
int roomdeaths[20 * 20];
int roomdeathsfinal[20 * 20];
Turn areamap into plain array For this one, I had to make it a static data member and then initialize it in a certain way in Map.cpp. It's pretty cool that you're able to do this.
2020-07-03 06:13:23 +02:00
static const int areamap[20 * 20];
Allow custom levels to use 2 billion tile numbers once again Ever since tilesheets got expanded, custom levels could use as many tiles as they wanted, as long as it fit under the 32-bit signed integer limit. Until 6c85fae339f83f032230eafaf8ee7742f03dbbac happened and they were reduced to 32,767 tiles. So I'm being generous again and changing the type of the contents array (in mapclass and editorclass) back to int. This won't affect the existing tilemaps of the main game, they'll still stay short arrays. But it means level makers can use 2 billion tiles once again.
2021-08-23 06:30:53 +02:00
int contents[40 * 30];
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
bool explored[20 * 20];
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Refactor explored rooms to use setters and getters This makes it easier to add bounds checks to all accesses of map.explored. Also, all manually-written existing bounds checks have been removed, because they're going to go into the new getters and setters. The getter is mapclass::isexplored() and the setter is mapclass::setexplored().
2021-03-24 20:12:39 +01:00
bool isexplored(const int rx, const int ry);
void setexplored(const int rx, const int ry, const bool status);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int background;
int rcol;
int tileset;
bool warpx;
bool warpy;
Replace roomnames/hiddennames/glitchnames with `const char*` Since those are all downstream recipients of either static storage or memory that doesn't move for the duration of the custom level, it's okay to make these be `const char*`s without having to redo any of the RAII memory management. mapclass::currentarea() is included in this as well. I also cleaned up Tower.cpp's headers to fix some transitive includes because I was removing UtilityClass.h includes from all other level files too. The "Untitled room" names no longer show any coordinates, because doing so would require complicated memory management that's completely unneeded. No one will ever see them, and if they do they already know they have a problem anyway. The only time they might be able to see them is if they corrupted the areamap, but this was only possible in 2.2 and previous by dying outside the room deaths array in Outside Dimension VVVVVV, which has since been patched out. Besides, sometimes the "Untitled room" gets overwritten by something else anyway (especially in Finalclass.cpp), so it really, really doesn't matter.
2021-09-12 21:48:15 +02:00
const char* roomname;
Indicate what special roomnames are in the levels This just adds booleans roomname_special to the level classes in preparation for the localization system to use them. 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-29 04:58:49 +01:00
bool roomname_special;
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
bool roomnameset;
Replace roomnames/hiddennames/glitchnames with `const char*` Since those are all downstream recipients of either static storage or memory that doesn't move for the duration of the custom level, it's okay to make these be `const char*`s without having to redo any of the RAII memory management. mapclass::currentarea() is included in this as well. I also cleaned up Tower.cpp's headers to fix some transitive includes because I was removing UtilityClass.h includes from all other level files too. The "Untitled room" names no longer show any coordinates, because doing so would require complicated memory management that's completely unneeded. No one will ever see them, and if they do they already know they have a problem anyway. The only time they might be able to see them is if they corrupted the areamap, but this was only possible in 2.2 and previous by dying outside the room deaths array in Outside Dimension VVVVVV, which has since been patched out. Besides, sometimes the "Untitled room" gets overwritten by something else anyway (especially in Finalclass.cpp), so it really, really doesn't matter.
2021-09-12 21:48:15 +02:00
const char* hiddenname;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
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
std::vector<Roomname> specialroomnames;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Special tower stuff
bool towermode;
Make map.[old]ypos ints instead of floats So... I did see that map.ypos was a float when I added over-30-FPS mode, because map.oldypos wasn't there before... I'm guessing that I kind of just ignored it at the time. But, c'mon, map.ypos and map.oldypos are always treated as ints, so there's literally no reason for them to be actually floats in reality. I didn't even know they were anything other than ints until I checked Map.h.
2021-04-17 08:48:54 +02:00
int ypos;
int oldypos;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int cameramode;
int cameraseek, cameraseekframe;
int resumedelay;
bool minitowermode;
Refactor tower background to use a separate object instead Previously, the tower background was controlled by a disparate set of attributes on Graphics and mapclass, and wasn't really encapsulated. (If that's what that word means, I don't particularly care about object-oriented lingo.) But now, all relevant things that a tower background has has been put into a TowerBG struct, so it will be easy to make multiple copies without having to duplicate the code that handles it.
2020-11-03 00:05:24 +01:00
int colstatedelay;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int colsuperstate;
int spikeleveltop, spikelevelbottom;
Interpolate spikeleveltop and spikelevelbottom This doesn't have much effect, except for when the spikes quickly move, because the spikes only usually move at 1 pixel per frame anyway.
2020-04-30 21:58:08 +02:00
int oldspikeleveltop, oldspikelevelbottom;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//final level navigation
bool finalmode;
bool finalstretch;
//Variables for playing custom levels
bool custommode;
bool custommodeforreal;
int custommmxoff, custommmyoff, custommmxsize, custommmysize;
int customzoom;
bool customshowmm;
//final level colour cycling stuff
bool final_colormode;
int final_mapcol;
int final_aniframe;
int final_aniframedelay;
int final_colorframe, final_colorframedelay;
//Teleporters and Trinkets on the map
Use `SDL_Point` instead of rolling our own `point` struct The `point` struct was a relic of ActionScript and was added because of the Flash 'point' object. However, it seems like Simon Roth didn't realize that SDL has its own point struct. With this, `Maths.h` can be un-included from a couple headers, which exposes the fact that `preloader.cpp` was relying on `Maths.h` being transitively included from `Graphics.h`.
2023-01-29 08:32:14 +01:00
std::vector<SDL_Point> teleporters;
std::vector<SDL_Point> shinytrinkets;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
bool showteleporters, showtargets, showtrinkets;
//Roomtext
bool roomtexton;
Refactor roomtext to not use ad-hoc objects / separate length trackers This refactors the roomtext code to (1) not use ad-hoc objects and (2) not use a separate length-tracking variable to keep track of the actual amount of roomtext in a room. What I mean by ad-hoc object is, instead of formally creating a fully-fledged struct or class and storing one vector containing that object, this game instead hacks together an object by storing each attribute of an object in different vectors. In the case of roomtext, instead of making a Roomtext object that has attributes 'x', 'y', and 'text', the 'text' attribute of each is stored in the vector 'roomtext', the 'x' attribute of each is stored in the vector 'roomtextx', and the 'y' attribute of each is stored in the vector 'roomtexty'. It's only an object in the sense that you can grab the attributes of each roomtext by using the same index across all three vectors. This makes it somewhat annoying to maintain and deal with, like when I wanted add sub-tile positions to roomtext in VVVVVV: Community Edition. Instead of being able to add attributes to an already-existing formalized Roomtext object, I would instead have to add two more vectors, which is inelegant. Or I could refactor the whole system, which is what I decided to do instead. Furthermore, this removes the separate length-tracking variable 'roomtextnumlines', which makes the code much more easy to maintain and deal with, as the amount of roomtext is naturally tracked by C++ instead of us having to keep track of the actual amount of roomtext manually.
2020-03-01 03:26:12 +01:00
std::vector<Roomtext> roomtext;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Levels
otherlevelclass otherlevel;
spacestation2class spacestation2;
labclass lablevel;
finalclass finallevel;
warpclass warplevel;
towerclass tower;
int extrarow;
//Accessibility options
bool invincibility;
//Map cursor
int cursorstate, cursordelay;
};
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 MAP_DEFINITION
Allow using help/graphics/music/game/key/map/obj everywhere This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and `obj` essentially static global objects that can be used everywhere. This is useful in case we ever need to add a new function in the future, so we don't have to bother with passing a new argument in which means we have to pass a new argument in to the function that calls that function which means having to pass a new argument into the function that calls THAT function, etc. which is a real headache when working on fan mods of the source code. Note that this changes NONE of the existing function signatures, it merely just makes those variables accessible everywhere in the same way `script` and `ed` are. Also note that some classes had to be initialized after the filesystem was initialized, but C++ would keep initializing them before the filesystem got initialized, because I *had* to put them at the top of `main.cpp`, or else they wouldn't be global variables. The only way to work around this was to use entityclass's initialization style (which I'm pretty sure entityclass of all things doesn't need to be initialized this way), where you actually initialize the class in an `init()` function, and so then you do `graphics.init()` after the filesystem initialization, AFTER doing `Graphics graphics` up at the top. I've had to do this for `graphics` (but only because its child GraphicsResources `grphx` needs to be initialized this way), `music`, and `game`. I don't think this will affect anything. Other than that, `help`, `key`, and `map` are still using the C++-intended method of having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
extern mapclass map;
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
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
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#endif /* MAPGAME_H */
Reference in a new issue Copy permalink