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/Map.cpp

2081 lines
48 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 MAP_DEFINITION
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "Map.h"
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
#include "editor.h"
#include "Entity.h"
#include "Game.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"
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
#include "Graphics.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 "MakeAndPlay.h"
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
#include "Music.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"
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
#include "UtilityClass.h"
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::mapclass(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Start here!
colstatedelay = 0;
colsuperstate = 0;
spikeleveltop = 0;
spikelevelbottom = 0;
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
oldspikeleveltop = 0;
oldspikelevelbottom = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
warpx = false;
warpy = false;
extrarow = 0;
showteleporters = false;
showtargets = false;
showtrinkets = false;
finalmode = false;
finalstretch = false;
cursorstate = 0;
cursordelay = 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
towermode = false;
cameraseekframe = 0;
resumedelay = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
final_colormode = false;
final_colorframe = 0;
final_colorframedelay = 0;
final_mapcol = 0;
final_aniframe = 0;
final_aniframedelay = 0;
custommode=false;
custommodeforreal=false;
customwidth=20; customheight=20;
custommmxoff=0; custommmyoff=0; custommmxsize=0; custommmysize=0;
customzoom=0;
customshowmm=true;
rcol = 0;
//This needs to be in map instead!
invincibility = false;
//We init the lookup table:
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
for (size_t i = 0; i < SDL_arraysize(vmult); i++)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
vmult[i] = i * 40;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
//We create a blank map
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
SDL_memset(contents, 0, sizeof(contents));
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
SDL_memset(roomdeaths, 0, sizeof(roomdeaths));
SDL_memset(roomdeathsfinal, 0, sizeof(roomdeathsfinal));
resetmap();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tileset = 0;
initmapdata();
resetnames();
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
ypos = 0;
oldypos = 0;
Ensure that all member attributes are initialized I ran the game through cppcheck and it spat out a bunch of member attributes that weren't being initialized. So I initialized them. In the previous version of this commit, I added constructors to GraphicsResources, otherlevelclass, labclass, warpclass, and finalclass, but flibit says this changes the code flow enough that it's risky to merge before 2.4, so I got rid of those constructors, too.
2020-07-06 22:04:34 +02:00
background = 0;
cameramode = 0;
cameraseek = 0;
minitowermode = false;
roomtexton = false;
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
}
//Areamap starts at 100,100 and extends 20x20
const int mapclass::areamap[] = {
Refactor areamap initialization to not use strings Instead, the data is held in a const int array, which is directly loaded into areamap.
2020-05-18 02:05:07 +02:00
1,2,2,2,2,2,2,2,0,3,0,0,0,4,4,4,4,4,4,4,
1,2,2,2,2,2,2,0,0,3,0,0,0,0,4,4,4,4,4,4,
0,1,0,0,2,0,0,0,0,3,0,0,0,0,4,4,4,4,4,4,
0,0,0,0,2,0,0,0,0,3,0,0,5,5,5,5,4,4,4,4,
0,0,2,2,2,0,0,0,0,3,11,11,5,5,5,5,0,0,0,0,
0,0,0,0,0,0,0,0,0,3,5,5,5,5,5,5,0,0,0,0,
0,0,0,0,0,0,0,0,0,3,5,5,5,5,5,5,5,0,0,0,
0,0,0,0,0,0,0,0,0,3,5,5,5,5,5,5,5,5,5,0,
0,0,0,0,0,0,0,0,0,3,0,0,0,5,5,5,5,5,5,0,
0,0,0,0,0,0,0,0,11,3,0,0,0,5,5,5,5,5,5,0,
0,0,0,0,0,0,0,0,0,3,0,0,0,5,5,5,5,5,5,0,
0,0,0,0,0,0,0,0,0,3,0,5,5,5,5,5,5,5,5,0,
0,0,0,0,0,0,0,0,0,3,0,5,5,5,5,5,5,0,5,0,
0,0,0,0,0,0,0,0,0,3,0,5,5,5,5,5,5,0,5,0,
0,0,0,0,0,0,0,0,0,3,0,5,5,0,0,0,0,0,5,0,
0,0,0,0,0,0,0,2,0,3,0,0,0,0,0,0,0,0,0,0,
0,0,2,2,2,2,2,2,0,3,0,0,0,0,0,0,0,0,0,0,
0,2,2,2,2,2,2,2,0,3,0,0,0,0,0,0,0,0,0,0,
2,2,2,2,2,0,0,2,0,3,0,0,0,0,0,0,0,0,0,0,
2,2,2,2,2,0,0,2,0,3,0,0,0,0,0,0,0,0,0,0,
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
};
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int mapclass::intpol(int a, int b, float c)
{
return static_cast<int>(a + ((b - a) * 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 mapclass::setteleporter(int x, int y)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Dynamically add teleporters instead of using indices That is, instead of doing the following: teleporters[0] = ...; teleporters[1] = ...; teleporters[2] = ...; ... Instead do: teleporters.push_back(...); teleporters.push_back(...); teleporters.push_back(...); ...
2020-04-15 04:25:12 +02:00
point temp;
temp.x = x;
temp.y = y;
teleporters.push_back(temp);
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 mapclass::settrinket(int x, int y)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Dynamically add shinytrinkets instead of using indices That is, instead of doing shinytrinkets[t] = ..., do shinytrinkets.push_back(...).
2020-04-15 04:34:10 +02:00
point temp;
temp.x = x;
temp.y = y;
shinytrinkets.push_back(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 mapclass::resetmap(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//clear the explored area of the map
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
SDL_memset(explored, 0, sizeof(explored));
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 mapclass::resetnames(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Reset all the special names
specialnames[0] = "Rear Window";
specialnames[1] = "On the Waterfront";
specialnames[2] = "The Untouchables";
specialnames[3] = "Television Newsveel";
specialnames[4] = "Vwitched";
specialnames[5] = "Gvnsmoke";
specialnames[6] = "Please enjoy these repeats";
specialnames[7] = "Try Jiggling the Antenna";
glitchmode = 0;
glitchdelay = 0;
}
void mapclass::transformname(int t)
{
//transform special names into new ones, one step at a time
glitchdelay--;
if(glitchdelay<=0)
{
switch(t)
{
case 3:
//Television Newsveel -> The 9 O'Clock News
if (specialnames[3] == "Television Newsveel")
{
specialnames[3] = "Television Newsvel";
}
else if (specialnames[3] == "Television Newsvel")
{
specialnames[3] = "TelevisvonvNewsvel";
}
else if (specialnames[3] == "TelevisvonvNewsvel")
{
specialnames[3] = "TvlvvvsvonvNevsvel";
}
else if (specialnames[3] == "TvlvvvsvonvNevsvel")
{
specialnames[3] = "vvvvvvsvovvNe svel";
}
else if (specialnames[3] == "vvvvvvsvovvNe svel")
{
specialnames[3] = "vhv vvv'vvovv vevl";
}
else if (specialnames[3] == "vhv vvv'vvovv vevl")
{
specialnames[3] = "vhv V v'Cvovv vewv";
}
else if (specialnames[3] == "vhv V v'Cvovv vewv")
{
specialnames[3] = "vhe 9 v'Cvovv vewv";
}
else if (specialnames[3] == "vhe 9 v'Cvovv vewv")
{
specialnames[3] = "vhe 9 v'Cvovv Newv";
}
else if (specialnames[3] == "vhe 9 v'Cvovv Newv")
{
specialnames[3] = "The 9 O'Cvovk Newv";
}
else if (specialnames[3] == "The 9 O'Cvovk Newv")
{
specialnames[3] = "The 9 O'Clock News";
}
break;
case 4:
//Vwitched -> Dial M for Murder
if (specialnames[4] == "Vwitched")
{
specialnames[4] = "Vwitvhed";
}
else if (specialnames[4] == "Vwitvhed")
{
specialnames[4] = "vVwivcvedv";
}
else if (specialnames[4] == "vVwivcvedv")
{
specialnames[4] = "vvvwMvcvMdvv";
}
else if (specialnames[4] == "vvvwMvcvMdvv")
{
specialnames[4] = "DvvvwMvfvvMdvvv";
}
else if (specialnames[4] == "DvvvwMvfvvMdvvv")
{
specialnames[4] = "Dvav Mvfvr Mdvvvv";
}
else if (specialnames[4] == "Dvav Mvfvr Mdvvvv")
{
specialnames[4] = "Diav M for Mdrver";
}
else if (specialnames[4] == "Diav M for Mdrver")
{
specialnames[4] = "Dial M for Murder";
}
break;
case 5:
//Gvnsmoke -> Gunsmoke 1966
if (specialnames[5] == "Gvnsmoke")
{
specialnames[5] = "Gvnsmove";
}
else if (specialnames[5] == "Gvnsmove")
{
specialnames[5] = "Gvnvmovevv";
}
else if (specialnames[5] == "Gvnvmovevv")
{
specialnames[5] = "Gunvmove1vv6";
}
else if (specialnames[5] == "Gunvmove1vv6")
{
specialnames[5] = "Vunsmoke 19v6";
}
else if (specialnames[5] == "Vunsmoke 19v6")
{
specialnames[5] = "Gunsmoke 1966";
}
break;
case 6:
//Please enjoy these repeats -> In the Margins
if (specialnames[6] == "Please enjoy these repeats")
{
specialnames[6] = "Please envoy theve repeats";
}
else if (specialnames[6] == "Please envoy theve repeats")
{
specialnames[6] = "Plse envoy tse rvpvas";
}
else if (specialnames[6] == "Plase envoy these rvpeas")
{
specialnames[6] = "Plse envoy tse rvpvas";
}
else if (specialnames[6] == "Plse envoy tse rvpvas")
{
specialnames[6] = "Vl envoy te rvevs";
}
else if (specialnames[6] == "Vl envoy te rvevs")
{
specialnames[6] = "Vv evo tv vevs";
}
else if (specialnames[6] == "Vv evo tv vevs")
{
specialnames[6] = "Iv vhv Mvrvivs";
}
else if (specialnames[6] == "Iv vhv Mvrvivs")
{
specialnames[6] = "In the Margins";
}
break;
case 7:
//Try Jiggling the Antenna -> Heaven's Gate
if (specialnames[7] == "Try Jiggling the Antenna")
{
specialnames[7] = "Try Viggling the Antenna";
}
else if (specialnames[7] == "Try Viggling the Antenna")
{
specialnames[7] = "TryJivglvng theAvtevna";
}
else if (specialnames[7] == "TryJivglvng theAvtevna")
{
specialnames[7] = "Tvvivglvng thAvtvvv";
}
else if (specialnames[7] == "Tvvivglvng thAvtvvv")
{
specialnames[7] = "Vvvgglvnv tvnvva";
}
else if (specialnames[7] == "Vvvgglvnv tvnvva")
{
specialnames[7] = "Vvavvnvs vvtv";
}
else if (specialnames[7] == "Vvavvnvs vvtv")
{
specialnames[7] = "Veavvn's Gvte";
}
else if (specialnames[7] == "Veavvn's Gvte")
{
specialnames[7] = "Heaven's Gate";
}
break;
}
glitchdelay = 5;
}
else
{
glitchdelay--;
}
}
std::string mapclass::getglitchname(int x, int y)
{
//Returns the name in the final area.
if (roomname == "glitch")
{
//8 Cases!
//First, the three "glitches"
glitchdelay--;
if (glitchdelay <= -5)
{
glitchmode = (glitchmode + 1) % 2;
glitchdelay = 0;
if (glitchmode == 0) glitchdelay = 20 +int(fRandom() * 10);
}
if (x == 42 && y == 51)
{
if (glitchmode == 0)
{
return specialnames[0];
}
else return "Rear Vindow";
}
else if (x == 48 && y == 51)
{
if (glitchmode == 0)
{
return specialnames[1];
}
else return "On the Vaterfront";
}
else if (x == 49 && y == 51)
{
if (glitchmode == 0)
{
return specialnames[2];
}
else return "The Untouchavles";
}
}
else if (roomname == "change")
{
if (finalstretch)
{
if (x == 45 && y == 51) transformname(3);
if (x == 46 && y == 51) transformname(4);
if (x == 47 && y == 51) transformname(5);
if (x == 50 && y == 53) transformname(6);
if (x == 50 && y == 54) transformname(7);
}
if (x == 45 && y == 51) return specialnames[3];
if (x == 46 && y == 51) return specialnames[4];
if (x == 47 && y == 51) return specialnames[5];
if (x == 50 && y == 53) return specialnames[6];
if (x == 50 && y == 54) return specialnames[7];
return roomname;
}
else
{
return roomname;
}
return roomname;
}
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 mapclass::initmapdata(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Scan for trinkets and put them into shinytrinkets in customs For showtrinkets() to work, we'll need the correct map data in custom levels.
2020-06-30 21:30:19 +02:00
if (custommode)
{
initcustommapdata();
return;
}
teleporters.clear();
shinytrinkets.clear();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Set up static map information like teleporters and shiny trinkets.
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
setteleporter(0, 0);
setteleporter(0, 16);
setteleporter(2, 4);
setteleporter(2, 11);
setteleporter(7, 9);
setteleporter(7, 15);
setteleporter(8, 11);
setteleporter(10, 5);
setteleporter(11, 4);
setteleporter(13, 2);
setteleporter(13, 8);
setteleporter(14, 19);
setteleporter(15, 0);
setteleporter(17, 12);
setteleporter(17, 17);
setteleporter(18, 1);
setteleporter(18, 7);
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
settrinket(14, 4);
settrinket(13, 6);
settrinket(11, 12);
settrinket(15, 12);
settrinket(14, 11);
settrinket(18, 14);
settrinket(11, 7);
settrinket(9, 2);
settrinket(9, 16);
settrinket(2, 18);
settrinket(7, 18);
settrinket(6, 1);
settrinket(17, 3);
settrinket(10, 19);
settrinket(5, 15);
settrinket(1, 10);
settrinket(3, 2);
settrinket(10, 8);
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 mapclass::initcustommapdata(void)
Scan for trinkets and put them into shinytrinkets in customs For showtrinkets() to work, we'll need the correct map data in custom levels.
2020-06-30 21:30:19 +02:00
{
shinytrinkets.clear();
#if !defined(NO_CUSTOM_LEVELS)
for (size_t i = 0; i < edentity.size(); i++)
{
const edentities& ent = edentity[i];
if (ent.t != 9)
{
continue;
}
const int rx = ent.x / 40;
const int ry = ent.y / 30;
settrinket(rx, ry);
}
#endif
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int mapclass::finalat(int x, int y)
{
//return the tile index of the final stretch tiles offset by the colour difference
if (contents[x + vmult[y]] == 740)
{
//Special case: animated tiles
if (final_mapcol == 1)
{
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
return 737 + (int(fRandom() * 11) * 40);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
return contents[x + vmult[y]] - (final_mapcol * 3) + (final_aniframe * 40);
}
}
else if (contents[x + vmult[y]] >= 80)
{
return contents[x + vmult[y]] - (final_mapcol * 3);
}
else
{
return contents[x + vmult[y]];
}
}
int mapclass::maptiletoenemycol(int t)
{
//returns the colour index for enemies that matches the map colour t
switch(t)
{
case 0:
return 11;
break;
case 1:
return 6;
break;
case 2:
return 8;
break;
case 3:
return 12;
break;
case 4:
return 9;
break;
case 5:
return 7;
break;
case 6:
return 18;
break;
}
return 11;
}
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 mapclass::changefinalcol(int t)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//change the map to colour t - for the game's final stretch.
//First up, the tiles. This is just a setting:
final_mapcol = t;
Move temp and temp2 off of mapclass There's no reason these temporary variables need to exist on the class exist.
2020-07-03 04:20:22 +02:00
int temp = 6 - t;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Next, entities
Refactor entities and linecrosskludge to not use the 'active' system This removes the variables obj.nentity and obj.nlinecrosskludge, as well as removing the 'active' attribute from the entity class object. Now every entity you access is guaranteed to be real and you don't have to check the 'active' variable. The biggest part of this is changing createentity() to modify a newly-created entity object and push it back instead of already modifying an indice in obj.entities. As well, removing an entity now uses the new obj.removeentity() function and removeentity_iter() macro.
2020-04-03 22:50:16 +02:00
for (size_t i = 0; i < obj.entities.size(); i++)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (obj.entities[i].type == 1) //something with a movement behavior
{
if (obj.entities[i].animate == 10 || obj.entities[i].animate == 11) //treadmill
{
if(temp<3)
{
obj.entities[i].tile = 907 + (temp * 80);
}
else
{
obj.entities[i].tile = 911 + ((temp-3) * 80);
}
if(obj.entities[i].animate == 10) obj.entities[i].tile += 40;
}
else if (obj.entities[i].isplatform)
{
obj.entities[i].tile = 915+(temp*40);
}
else //just an enemy
{
obj.entities[i].colour = maptiletoenemycol(temp);
}
}
else if (obj.entities[i].type == 2) //disappearing platforms
{
obj.entities[i].tile = 915+(temp*40);
}
}
}
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 mapclass::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)
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
bg_obj.r = intpol(r1, r2, c / 5);
bg_obj.g = intpol(g1, g2, c / 5);
bg_obj.b = intpol(b1, b2, c / 5);
}
void mapclass::updatebgobj(TowerBG& bg_obj)
{
const int check = bg_obj.colstate % 5; //current state of phase
const int cmode = (bg_obj.colstate - check) / 5; // current colour transition;
switch(cmode)
{
case 0:
setcol(bg_obj, 255, 93, 107, 255, 255, 93, check);
break;
case 1:
setcol(bg_obj, 255, 255, 93, 159, 255, 93, check);
break;
case 2:
setcol(bg_obj, 159, 255, 93, 93, 245, 255, check);
break;
case 3:
setcol(bg_obj, 93, 245, 255, 177, 93, 255, check);
break;
case 4:
setcol(bg_obj, 177, 93, 255, 255, 93, 255, check);
break;
case 5:
setcol(bg_obj, 255, 93, 255, 255, 93, 107, check);
break;
}
bg_obj.tdrawback = true;
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 mapclass::setbgobjlerp(TowerBG& bg_obj)
{
bg_obj.bypos = ypos / 2;
bg_obj.bscroll = (ypos - oldypos) / 2;
}
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 mapclass::updatetowerglow(TowerBG& bg_obj)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (colstatedelay <= 0 || colsuperstate > 0)
{
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
if (colsuperstate > 0) bg_obj.colstate--;
bg_obj.colstate++;
if (bg_obj.colstate >= 30) bg_obj.colstate = 0;
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
const int check = bg_obj.colstate % 5;
updatebgobj(bg_obj);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (check == 0)
{
colstatedelay = 45;
}
else
{
colstatedelay = 0;
}
if (colsuperstate > 0) colstatedelay = 0;
}
else
{
colstatedelay--;
}
}
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 mapclass::nexttowercolour(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01: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.colstate+=5;
if (graphics.titlebg.colstate >= 30) graphics.titlebg.colstate = 0;
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
updatebgobj(graphics.titlebg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
void mapclass::settowercolour(int t)
{
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.colstate=t*5;
if (graphics.titlebg.colstate >= 30) graphics.titlebg.colstate = 0;
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
updatebgobj(graphics.titlebg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
bool mapclass::spikecollide(int x, int y)
{
if (invincibility) return false;
if (tower.at(x,y,0)>= 6 && tower.at(x,y,0) <= 11) return true;
return false;
}
bool mapclass::collide(int x, int y)
{
if (towermode)
{
if (tower.at(x, y, 0) >= 12 && tower.at(x, y, 0) <= 27) return true;
Make tiles in tower mode behave consistently with tower tileset elsewhere Previously, in tower mode, being inside walls would just kill you, unlike being inside walls outside tower mode, which was somewhat confusing. Also, spikes behaved differently with regards to invincibility, being unsolid in towers but solid outside them. This does not change the behaviour of the "edge" spikes in towers.
2020-02-05 22:02:00 +01:00
if (invincibility)
{
if (tower.at(x, y, 0) >= 6 && tower.at(x, y, 0) <= 11) return true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (tileset == 2)
{
if (y == -1) return collide(x, y + 1);
if (y == 29+extrarow) return collide(x, y - 1);
if (x == -1) return collide(x + 1, y);
if (x == 40) return collide(x - 1, y);
if (x < 0 || y < 0 || x >= 40 || y >= 29 + extrarow) return false;
if (contents[x + vmult[y]] >= 12 && contents[x + vmult[y]] <= 27) return true;
if (invincibility)
{
if (contents[x + vmult[y]] >= 6 && contents[x + vmult[y]] <= 11) return true;
}
}
else
{
if (y == -1) return collide(x, y + 1);
if (y == 29+extrarow) return collide(x, y - 1);
if (x == -1) return collide(x + 1, y);
if (x == 40) return collide(x - 1, y);
if (x < 0 || y < 0 || x >= 40 || y >= 29+extrarow) return false;
if (contents[x + vmult[y]] == 1) return true;
if (tileset==0 && contents[x + vmult[y]] == 59) return true;
if (contents[x + vmult[y]]>= 80 && contents[x + vmult[y]] < 680) return true;
if (contents[x + vmult[y]] == 740 && tileset==1) return true;
if (invincibility)
{
if (contents[x + vmult[y]]>= 6 && contents[x + vmult[y]] <= 9) return true;
if (contents[x + vmult[y]]>= 49 && contents[x + vmult[y]] <= 50) return true;
if (tileset == 1)
{
if (contents[x + vmult[y]]>= 49 && contents[x + vmult[y]] < 80) return true;
}
}
}
return false;
}
void mapclass::settile(int xp, int yp, int t)
{
if (xp >= 0 && xp < 40 && yp >= 0 && yp < 29+extrarow)
{
contents[xp + vmult[yp]] = t;
}
}
int mapclass::area(int _rx, int _ry)
{
//THIS IS THE BUG
if (finalmode)
{
return 6;
}
else
{
int lookup = (_rx - 100) + ((_ry - 100) * 20);
if(_rx-100>=0 && _rx-100<20 && _ry-100>=0 && _ry-100<20){
return areamap[lookup];
}
else
{
return 6;
}
}
}
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 mapclass::isexplored(const int rx, const int ry)
{
const int roomnum = rx + ry*20;
Add bounds checks to room explored getter and setter This means you can no longer cause Undefined Behavior by exploring a room that is outside the array of explored room statuses.
2021-03-24 20:14:28 +01:00
if (INBOUNDS_ARR(roomnum, explored))
{
return explored[roomnum];
}
return false;
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
}
void mapclass::setexplored(const int rx, const int ry, const bool status)
{
const int roomnum = rx + ry*20;
Add bounds checks to room explored getter and setter This means you can no longer cause Undefined Behavior by exploring a room that is outside the array of explored room statuses.
2021-03-24 20:14:28 +01:00
if (INBOUNDS_ARR(roomnum, explored))
{
explored[roomnum] = status;
}
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
}
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 mapclass::exploretower(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
for (int i = 0; i < 20; i++)
{
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
setexplored(9, i, true);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void mapclass::hideship(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//remove the ship from the explored areas
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
setexplored(2, 10, false);
setexplored(3, 10, false);
setexplored(4, 10, false);
setexplored(2, 11, false);
setexplored(3, 11, false);
setexplored(4, 11, false);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void mapclass::showship(void)
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
//show the ship in the explored areas
setexplored(2, 10, true);
setexplored(3, 10, true);
setexplored(4, 10, true);
setexplored(2, 11, true);
setexplored(3, 11, true);
setexplored(4, 11, true);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void mapclass::resetplayer(void)
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
{
resetplayer(false);
}
void mapclass::resetplayer(const bool player_died)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Fix minor issue with respawning into a tower When the game enter towermode, it adjusts player amd camera x/y depending on what screen the player entered it from (The Tower) or the loadlevel mode ("minitowers"; Panic Room and The Final Challenge). This code didn't account for respawning to checkpoints. This is unlikely to matter in most circumstances, but can cause problems in some corner cases, or with R abuse. This could cause a player to die, respawn outside camera edges and then immediately die again due to the edge spikes, repositioning the camera properly. Invincibility would cause further issues, but that's Invincibility Mode for you -- if this was the only problem I wouldn't bother. I added a check that repositions the tower camera appropriately if a player enter a tower as part of the respawn process.
2020-01-25 19:20:37 +01:00
bool was_in_tower = towermode;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.roomx != game.saverx || game.roomy != game.savery)
{
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
gotoroom(game.saverx, game.savery);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
game.deathseq = -1;
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))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[i].vx = 0;
obj.entities[i].vy = 0;
obj.entities[i].ax = 0;
obj.entities[i].ay = 0;
obj.entities[i].xp = game.savex;
obj.entities[i].yp = game.savey;
Re-fix glitchy y-position when spawning onto a conveyor This is a re-do of 942217f871bf1182ded3a915b8c26b90c04d561a (#509), but with a more conservative fix that only resets the player's newxp and newyp when they respawn from a checkpoint or spawn in to the map. Unlike the previous patch, if the player were to suddenly collide with a conveyor or horizontally-moving platform during gameplay, their y-position would revert back to the intended next y-position of the previous frame. But this is the same behavior as before, I haven't ever seen such a contrived situation come up, and this behavior is probably more preferable for gameplay than actually going to the conveyor, so it's fine. I also decided to reset newxp here, and not just newyp, because while resetting newyp seems to be enough, it's safer to also reset newxp (and so future readers won't question why only newyp is reset but not newxp). I tested this and it once again fixes the death loop issue from earlier, while also still allowing for that Trench Warfare trick to be possible (I tested it with the libTAS movie I mentioned in #606; it syncs fine). There are no other known regressions resulting from this fix (hopefully).
2021-02-02 01:16:04 +01:00
//Fix conveyor death loop glitch
obj.entities[i].newxp = obj.entities[i].xp;
obj.entities[i].newyp = obj.entities[i].yp;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.entities[i].dir = game.savedir;
obj.entities[i].colour = 0;
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
if (player_died)
{
game.lifeseq = 10;
obj.entities[i].invis = true;
}
Reset invis and lifeseq when loading in, in mapclass::resetplayer() When I did #569, I forgot that taking out the code path that set the player's invis to false meant that the player would still be invisible upon loading back in to the game if they exited the game while invisible. Taking out that code path also meant that if game.lifeseq was nonzero, it wouldn't be reset properly, either. So this fixes those things.
2020-12-28 22:23:42 +01:00
else
{
obj.entities[i].invis = false;
}
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
if (!GlitchrunnerMode_less_than_or_equal(Glitchrunner2_2))
Un-fix hitbox persistence in map.resetplayer() It's annoying for casuals to have to close the game if they manage to get themselves to turn into VVVVVV-Man, but it's amusing enough to glitchrunners that they mess about with VVVVVV-Man in the main game, clipping through walls everywhere (well, they call it Big Viridian, but still).
2020-06-25 23:56:09 +02:00
{
obj.entities[i].size = 0;
obj.entities[i].cx = 6;
obj.entities[i].cy = 2;
Reset width of player in mapclass::resetplayer() The width of the player can be changed by using the Gravitron OoB glitch. It will not be reset if the game is in glitchrunner mode.
2020-06-30 00:34:13 +02:00
obj.entities[i].w = 12;
Un-fix hitbox persistence in map.resetplayer() It's annoying for casuals to have to close the game if they manage to get themselves to turn into VVVVVV-Man, but it's amusing enough to glitchrunners that they mess about with VVVVVV-Man in the main game, clipping through walls everywhere (well, they call it Big Viridian, but still).
2020-06-25 23:56:09 +02:00
obj.entities[i].h = 21;
}
Fix minor issue with respawning into a tower When the game enter towermode, it adjusts player amd camera x/y depending on what screen the player entered it from (The Tower) or the loadlevel mode ("minitowers"; Panic Room and The Final Challenge). This code didn't account for respawning to checkpoints. This is unlikely to matter in most circumstances, but can cause problems in some corner cases, or with R abuse. This could cause a player to die, respawn outside camera edges and then immediately die again due to the edge spikes, repositioning the camera properly. Invincibility would cause further issues, but that's Invincibility Mode for you -- if this was the only problem I wouldn't bother. I added a check that repositions the tower camera appropriately if a player enter a tower as part of the respawn process.
2020-01-25 19:20:37 +01:00
// If we entered a tower as part of respawn, reposition camera
if (!was_in_tower && towermode)
{
ypos = obj.entities[i].yp - 120;
if (ypos < 0)
{
ypos = 0;
}
Set map.ypos when entering tower To prevent the camera "zipping" when entering a tower.
2020-04-30 21:02:52 +02:00
oldypos = ypos;
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
setbgobjlerp(graphics.towerbg);
Fix minor issue with respawning into a tower When the game enter towermode, it adjusts player amd camera x/y depending on what screen the player entered it from (The Tower) or the loadlevel mode ("minitowers"; Panic Room and The Final Challenge). This code didn't account for respawning to checkpoints. This is unlikely to matter in most circumstances, but can cause problems in some corner cases, or with R abuse. This could cause a player to die, respawn outside camera edges and then immediately die again due to the edge spikes, repositioning the camera properly. Invincibility would cause further issues, but that's Invincibility Mode for you -- if this was the only problem I wouldn't bother. I added a check that repositions the tower camera appropriately if a player enter a tower as part of the respawn process.
2020-01-25 19:20:37 +01:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
game.scmhurt = false; //Just in case the supercrewmate is fucking this up!
if (game.supercrewmate)
{
if (game.roomx == game.scmprogress + 41)
{
game.scmprogress = game.roomx - 41;
}
else
{
game.scmprogress = game.roomx - 40;
}
if (game.scmprogress != 0)
{
game.scmmoveme = true;
}
else
{
game.scmmoveme = false;
}
}
}
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 mapclass::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
gotoroom(rx, ry);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.teleport = false;
Rename INBOUNDS() macro to INBOUNDS_VEC() Since there's an INBOUNDS_ARR() macro, it's much better to specify the macro for the vector is a macro for the vector, to avoid confusion. All usages of this macro have been renamed accordingly.
2020-09-08 09:31:44 +02:00
if (INBOUNDS_VEC(t, 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[t].xp = tx * 8;
obj.entities[t].yp = (ty * 8) - obj.entities[t].h;
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[t].lerpoldxp = obj.entities[t].xp;
obj.entities[t].lerpoldyp = obj.entities[t].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
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.gravitycontrol = 0;
}
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 mapclass::gotoroom(int rx, int ry)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//First, destroy the current room
obj.removeallblocks();
game.activetele = false;
game.readytotele = 0;
Fix oldreadytotele not being set in gotoroom() This fixes a deltaframe glitch where the "- Press ENTER to Teleport -" prompt would show up for a split second if you exited the game while the prompt was fully faded in, and then re-entered it.
2020-11-04 09:53:43 +01:00
game.oldreadytotele = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Ok, let's save the position of all lines on the screen
Refactor entities and linecrosskludge to not use the 'active' system This removes the variables obj.nentity and obj.nlinecrosskludge, as well as removing the 'active' attribute from the entity class object. Now every entity you access is guaranteed to be real and you don't have to check the 'active' variable. The biggest part of this is changing createentity() to modify a newly-created entity object and push it back instead of already modifying an indice in obj.entities. As well, removing an entity now uses the new obj.removeentity() function and removeentity_iter() macro.
2020-04-03 22:50:16 +02:00
obj.linecrosskludge.clear();
for (size_t i = 0; i < obj.entities.size(); i++)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Refactor entities and linecrosskludge to not use the 'active' system This removes the variables obj.nentity and obj.nlinecrosskludge, as well as removing the 'active' attribute from the entity class object. Now every entity you access is guaranteed to be real and you don't have to check the 'active' variable. The biggest part of this is changing createentity() to modify a newly-created entity object and push it back instead of already modifying an indice in obj.entities. As well, removing an entity now uses the new obj.removeentity() function and removeentity_iter() macro.
2020-04-03 22:50:16 +02:00
if (obj.entities[i].type == 9)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//It's a horizontal line
if (obj.entities[i].xp <= 0 || (obj.entities[i].xp + obj.entities[i].w) >= 312)
{
//it's on a screen edge
obj.copylinecross(i);
}
}
}
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
/* Disable all entities in the room, and deallocate any unnecessary entity slots. */
/* However don't disable player entities, but do preserve holes between them (if any). */
bool player_found = false;
for (int i = obj.entities.size() - 1; i >= 0; --i)
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
/* Iterate in reverse order to prevent unnecessary indice shifting */
if (obj.entities[i].rule == 0)
{
player_found = true;
continue;
}
if (!player_found)
{
obj.entities.erase(obj.entities.begin() + i);
}
else
Destroy duplicate player entities during gotoroom The game makes sure that the player entity is never destroyed, but in doing so, it doesn't destroy any duplicate player entities that might have been created via strange means e.g. a custom level doing a createentity with t=0. Duplicate player entities are, in a sense, not the "real" player entity. For one, they can take damage and die, but when they do they'll still be stuck inside the hazard, which can result in a softlock. For another, their position isn't updated when going between rooms. It's better to just destroy them when we can.
2020-01-13 23:43:11 +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);
Destroy duplicate player entities during gotoroom The game makes sure that the player entity is never destroyed, but in doing so, it doesn't destroy any duplicate player entities that might have been created via strange means e.g. a custom level doing a createentity with t=0. Duplicate player entities are, in a sense, not the "real" player entity. For one, they can take damage and die, but when they do they'll still be stuck inside the hazard, which can result in a softlock. For another, their position isn't updated when going between rooms. It's better to just destroy them when we can.
2020-01-13 23:43:11 +01:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
game.door_up = rx + ((ry - 1) * 100);
game.door_down = rx + ((ry + 1) * 100);
game.door_right = rx + 1 + (ry * 100);
game.door_left = rx -1 + (ry * 100);
if (rx < game.roomx)
{
game.roomchangedir = 0;
}
else
{
game.roomchangedir = 1;
}
if (finalmode)
{
//Ok, what way are we moving?
Remove map.finalx/y and map.customx/y These variables basically serve no purpose. map.customx and map.customy are clearly never used. map.finalx and map.finaly, on the other hand, are basically always game.roomx and game.roomy respectively if map.finalmode is on, and if it's off, then they don't matter. Also, there are some weird and redundant variable assignments going on with these; most notably in map.gotoroom(), where rx/ry (local variables) get assigned to finalx/finaly, then finalx/finaly get assigned to game.roomx/game.roomy, then finalx/finaly get assigned to rx/ry. If finalx/finaly made a difference, then there'd be no need to assign finalx/finaly back to rx/ry. So it makes the code clearer to remove these weird bits of code.
2021-01-11 04:58:36 +01:00
game.roomx = rx;
game.roomy = ry;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.roomchange = true;
if (game.roomy < 10)
{
game.roomy = 11;
}
if(game.roomx>=41 && game.roomy>=48 && game.roomx<61 && game.roomy<68 )
{
game.currentroomdeaths = roomdeathsfinal[game.roomx - 41 + (20 * (game.roomy - 48))];
}
else
{
game.currentroomdeaths = 0;
}
//Final level for time trial
if (game.intimetrial)
{
if (game.roomx == 46 && game.roomy == 54) music.niceplay(15); //Final level remix
}
}
Add option to allow custom levels when the editor is disabled
2020-02-10 03:21:19 +01:00
#if !defined(NO_CUSTOM_LEVELS)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
else if (custommode)
{
game.roomx = rx;
game.roomy = ry;
game.roomchange = true;
if (game.roomx < 100) game.roomx = 100 + ed.mapwidth-1;
if (game.roomy < 100) game.roomy = 100 + ed.mapheight-1;
if (game.roomx > 100 + ed.mapwidth-1) game.roomx = 100;
if (game.roomy > 100 + ed.mapheight-1) game.roomy = 100;
}
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
else
{
game.roomx = rx;
game.roomy = ry;
game.roomchange = true;
if (game.roomx < 100) game.roomx = 119;
if (game.roomy < 100) game.roomy = 119;
if (game.roomx > 119) game.roomx = 100;
if (game.roomy > 119) game.roomy = 100;
game.currentroomdeaths = roomdeaths[game.roomx - 100 + (20 * (game.roomy - 100))];
//Alright, change music depending on where we are:
//Tower
if (game.roomx == 107 && game.roomy == 106) music.niceplay(4);
if (game.roomx == 107 && game.roomy == 107) music.niceplay(4);
if (game.roomx == 107 && game.roomy == 108) music.niceplay(4);
if (game.roomx == 107 && game.roomy == 109) music.niceplay(4);
if (game.roomx == 108 && game.roomy == 109)
{
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
if (graphics.setflipmode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
music.niceplay(9);
}
else
{
music.niceplay(2);
}
}
if (game.roomx == 109)
{
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
if (graphics.setflipmode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
music.niceplay(9);
}
else
{
music.niceplay(2);
}
}
//Warp Zone
if (game.roomx == 112 && game.roomy == 101) music.niceplay(4);
if (game.roomx == 113 && game.roomy == 101) music.niceplay(4);
if (game.roomx == 113 && game.roomy == 102) music.niceplay(4);
if (game.roomx == 114 && game.roomy == 101) music.niceplay(12);
if (game.roomx == 115 && game.roomy == 101) music.niceplay(12);
if (game.roomx == 115 && game.roomy == 102) music.niceplay(12);
//Lab
if (game.roomx == 101 && game.roomy == 115) music.niceplay(4);
if (game.roomx == 100 && game.roomy == 115) music.niceplay(4);
if (game.roomx == 101 && game.roomy == 116) music.niceplay(4);
if (game.roomx == 100 && game.roomy == 116) music.niceplay(4);
if (game.roomx == 102 && game.roomy == 116) music.niceplay(3);
if (game.roomx == 102 && game.roomy == 117) music.niceplay(3);
if (game.roomx == 101 && game.roomy == 117) music.niceplay(3);
//Space Station
if (game.intimetrial)
{
if (game.roomx == 111 && game.roomy == 112) music.niceplay(1);
if (game.roomx == 111 && game.roomy == 113) music.niceplay(1);
if (game.roomx == 112 && game.roomy == 114) music.niceplay(1);
if (game.roomx == 112 && game.roomy == 115) music.niceplay(1);
}
else
{
if (game.roomx == 111 && game.roomy == 112) music.niceplay(1);
if (game.roomx == 111 && game.roomy == 113) music.niceplay(1);
if (game.roomx == 112 && game.roomy == 114) music.niceplay(4);
if (game.roomx == 112 && game.roomy == 115) music.niceplay(4);
}
//Leaving the Ship
if (game.roomx == 104 && game.roomy == 112) music.niceplay(4);
}
Move temp and temp2 off of mapclass There's no reason these temporary variables need to exist on the class exist.
2020-07-03 04:20:22 +02:00
int temp = rx + (ry * 100);
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
loadlevel(game.roomx, game.roomy);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't redraw H/V warp BG if gotorooming to same room in customs This has two benefits: (1) The game uses less resources when it is asked to gotoroom to the same room because it is no longer redrawing the warp background every single frame, which is very wasteful. (2) The warp background no longer freezes or flickers if the player is standing inside a gotoroom script box (which calls gotoroom every frame or every other frame, because every time the gotoroom happens the script box gets reloaded).
2020-01-27 23:46:11 +01:00
//Do we need to reload the background?
bool redrawbg = game.roomx != game.prevroomx || game.roomy != game.prevroomy;
if(redrawbg)
{
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
graphics.backgrounddrawn = false; //Used for background caching speedup
Don't redraw H/V warp BG if gotorooming to same room in customs This has two benefits: (1) The game uses less resources when it is asked to gotoroom to the same room because it is no longer redrawing the warp background every single frame, which is very wasteful. (2) The warp background no longer freezes or flickers if the player is standing inside a gotoroom script box (which calls gotoroom every frame or every other frame, because every time the gotoroom happens the script box gets reloaded).
2020-01-27 23:46:11 +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
graphics.foregrounddrawn = false; //Used for background caching speedup
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Don't redraw H/V warp BG if gotorooming to same room in customs This has two benefits: (1) The game uses less resources when it is asked to gotoroom to the same room because it is no longer redrawing the warp background every single frame, which is very wasteful. (2) The warp background no longer freezes or flickers if the player is standing inside a gotoroom script box (which calls gotoroom every frame or every other frame, because every time the gotoroom happens the script box gets reloaded).
2020-01-27 23:46:11 +01:00
game.prevroomx = game.roomx;
game.prevroomy = game.roomy;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//a very special case: if entering the communication room, room 13,4 before tag 5 is set, set the game state to a background
//textbox thingy. if tag five is not set when changing room, reset the game state. (tag 5 is set when you get back to the ship)
if(!game.intimetrial && !custommode)
{
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] && !finalmode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
game.state = 0;
if (game.roomx == 113 && game.roomy == 104)
{
game.state = 50;
}
}
}
//Ok, kludge to fix lines in crossing rooms - if we're intersecting a gravity line right now, let's
//set it to an inactive state.
//Alright! So, let's look at our lines from the previous rooms, and determine if any of them are actually
//continuations!
temp = 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(temp, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Re-add original oldxp/oldyp assignments in gotoroom() The intent of #504 was to make it so oldxp/oldyp would never be messed with for over-30-FPS stuff, but I forgot that I changed these assignments in my over-30-FPS patch when I was doing #504. So these assignments have been restored to the way they were in 2.2, and is fixed now.
2020-11-01 05:57:08 +01:00
obj.entities[temp].oldxp = obj.entities[temp].xp;
obj.entities[temp].oldyp = obj.entities[temp].yp;
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[temp].lerpoldxp = obj.entities[temp].xp - int(obj.entities[temp].vx);
obj.entities[temp].lerpoldyp = obj.entities[temp].yp - int(obj.entities[temp].vy);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Refactor entities and linecrosskludge to not use the 'active' system This removes the variables obj.nentity and obj.nlinecrosskludge, as well as removing the 'active' attribute from the entity class object. Now every entity you access is guaranteed to be real and you don't have to check the 'active' variable. The biggest part of this is changing createentity() to modify a newly-created entity object and push it back instead of already modifying an indice in obj.entities. As well, removing an entity now uses the new obj.removeentity() function and removeentity_iter() macro.
2020-04-03 22:50:16 +02:00
for (size_t i = 0; i < obj.entities.size(); i++)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Refactor entities and linecrosskludge to not use the 'active' system This removes the variables obj.nentity and obj.nlinecrosskludge, as well as removing the 'active' attribute from the entity class object. Now every entity you access is guaranteed to be real and you don't have to check the 'active' variable. The biggest part of this is changing createentity() to modify a newly-created entity object and push it back instead of already modifying an indice in obj.entities. As well, removing an entity now uses the new obj.removeentity() function and removeentity_iter() macro.
2020-04-03 22:50:16 +02:00
if (obj.entities[i].type == 9)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//It's a horizontal line
if (obj.entities[i].xp <= 0 || obj.entities[i].xp + obj.entities[i].w >= 312)
{
//it's on a screen edge
Remove i/j/k attributes from classes that don't need them The only class that actually needs its i/j/k kept is scriptclass, because some custom levels rely on it for creating custom activity zones. So I haven't touched that. Other than that, there's no chance that anything important relies on i/j/k in any other class. For that to be the case, it would have to use i/j/k without initializing it beforehand, and that can simply be detected by removing the attribute from the header file and seeing where the compiler complains. And the compiler complains only about cases where it's initialized first. (Note that due to this check, I *haven't* removed Graphics's `m` as it precisely does exactly this, using it without initializing it first.) Interestingly enough, otherlevelclass and towerclass have unused i/k variables for whatever reason.
2020-06-14 20:21:32 +02:00
for (size_t j = 0; j < obj.linecrosskludge.size(); j++)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (obj.entities[i].yp == obj.linecrosskludge[j].yp)
{
//y's match, how about x's?
//we're moving left:
if (game.roomchangedir == 0)
{
if (obj.entities[i].xp + obj.entities[i].w >= 312 && obj.linecrosskludge[j].xp <= 0)
{
obj.revertlinecross(i, j);
}
}
else
{
if (obj.entities[i].xp <= 0 && obj.linecrosskludge[j].xp + obj.linecrosskludge[j].w >= 312)
{
obj.revertlinecross(i, j);
}
}
}
}
}
}
}
}
std::string mapclass::currentarea(int t)
{
switch(t)
{
case 0:
return "Dimension VVVVVV";
break;
case 1:
return "Dimension VVVVVV";
break;
case 2:
return "Laboratory";
break;
case 3:
return "The Tower";
break;
case 4:
Correct Warp Zone's area name from "Warpzone" to "Warp Zone" This is the name that gets displayed in your save file.
2020-01-16 02:24:56 +01:00
return "Warp Zone";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 5:
return "Space Station";
break;
case 6:
return "Outside Dimension VVVVVV";
break;
case 7:
return "Outside Dimension VVVVVV";
break;
case 8:
return "Outside Dimension VVVVVV";
break;
case 9:
return "Outside Dimension VVVVVV";
break;
case 10:
return "Outside Dimension VVVVVV";
break;
case 11:
return "The Tower";
break;
}
return "???";
}
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 mapclass::loadlevel(int rx, int ry)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
int t;
if (!finalmode)
{
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
setexplored(rx - 100, ry - 100, true);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (rx == 109 && !custommode)
{
exploretower();
}
}
roomtexton = false;
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
roomtext.clear();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.platformtile = 0;
obj.customplatformtile=0;
obj.vertplatforms = false;
obj.horplatforms = false;
roomname = "";
Refactor how "hidden names" work By "hidden names", I'm referring to "Dimension VVVVVV" and "The Ship" popping up on the quit/pause/teleporter screens, even though those rooms don't have any roomnames. Apparently my commit to fix roomname re-draw bleed on the quit/pause/teleporter screens exposed yet another hardreset()-caused bug. The issue here is that since hardreset() sets game.roomx and game.roomy to 0, map.area() will no longer work properly, and since the hidden roomname check is based on map.area(), it will no longer display "Dimension VVVVVV" or "The Ship" once you press ACTION to quit. It used to do this due to the re-draw bleed, but now it doesn't. I saw that roomnames didn't get reset in hardreset(), so the solution here is to re-factor hidden names to be an actual variable, instead of being implicit. map.hiddenname is a variable that's set in mapclass::loadlevel(), and if isn't empty, it will be drawn on the quit/pause/teleporter screens. That way it will still display "Dimension VVVVVV" and "The Ship" when you press ACTION to quit to the menu. EDIT: Since PR #230 got merged, this commit is no longer strictly necessary, but it's still good to refactor hidden names like this.
2020-05-02 23:10:22 +02:00
hiddenname = "";
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
background = 1;
warpx = false;
warpy = false;
towermode = false;
ypos = 0;
Set map.ypos when entering tower To prevent the camera "zipping" when entering a tower.
2020-04-30 21:02:52 +02:00
oldypos = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
extrarow = 0;
Reset spikeleveltop and spikelevelbottom in mapclass::loadlevel() Just a small thing, but if you teleported out of a tower with the top/bottom screen spikes being onscreen (by dying, for example), they would retract once you went back in to a tower. Small little thing, but it's a good thing to polish.
2020-04-30 21:50:45 +02:00
spikeleveltop = 0;
spikelevelbottom = 0;
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
oldspikeleveltop = 0;
oldspikelevelbottom = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Custom stuff for warplines
obj.customwarpmode=false;
obj.customwarpmodevon=false;
obj.customwarpmodehon=false;
if (finalmode)
{
t = 6;
//check if we're in the towers
if (rx == 49 && ry == 52)
{
//entered tower 1
t = 7;
}
else if (rx == 49 && ry == 53)
{
//re entered tower 1
t = 8;
}
else if (rx == 51 && ry == 54)
{
//entered tower 2
t = 9;
}
else if (rx == 51 && ry == 53)
{
//re entered tower 2
t = 10;
}
}
else if (custommode)
{
t= 12;
}
else
{
t = area(rx, ry);
if (t == 3)
{
//correct position for tower
if (ry == 109)
{
//entered from ground floor
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))
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[player].yp += (671 * 8);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
ypos = (700-29) * 8;
Set map.ypos when entering tower To prevent the camera "zipping" when entering a tower.
2020-04-30 21:02:52 +02:00
oldypos = ypos;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
cameramode = 0;
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
graphics.towerbg.colstate = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
colsuperstate = 0;
}
else if (ry == 104)
{
//you've entered from the top floor
ypos = 0;
Set map.ypos when entering tower To prevent the camera "zipping" when entering a tower.
2020-04-30 21:02:52 +02:00
oldypos = ypos;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
cameramode = 0;
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
graphics.towerbg.colstate = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
colsuperstate = 0;
}
}
if (t < 2) //on the world map, want to test if we're in the secret lab
{
if (rx >= 116)
{
if (ry >= 105)
{
if (ry <= 107)
{
if (rx == 119 && ry == 105)
{
//Ah, this is just a normal area
}
else
{
//in the secret lab! Crazy background!
background = 2;
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
if (rx == 116 && ry == 105) graphics.rcol = 1;
if (rx == 117 && ry == 105) graphics.rcol = 5;
if (rx == 118 && ry == 105) graphics.rcol = 4;
if (rx == 117 && ry == 106) graphics.rcol = 2;
if (rx == 118 && ry == 106) graphics.rcol = 0;
if (rx == 119 && ry == 106) graphics.rcol = 3;
if (rx == 119 && ry == 107) graphics.rcol = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
}
}
}
Fix hardcoded (19,8) all-sides warp happening in custom levels (19,8) is hardcoded to warp on all-sides no matter what. This is fine, except for the fact that it was doing this in custom levels, too, even despite the fact that the warp background and color would be overridden anyway. The only workaround was to add a warp line to the room in custom levels. I've added a check for custommode so that this won't happen.
2020-02-02 11:37:23 +01:00
if (rx == 119 && ry == 108 && !custommode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
background = 5;
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
graphics.rcol = 3;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
warpx = true;
warpy = true;
}
switch(t)
{
Fix mixed indentation in Map.h and Map.cpp Again, not that much. These files more-or-less consistently use their respective indentation.
2020-04-02 22:09:22 +02:00
#if !defined(MAKEANDPLAY)
Fix compile failure if both MAKEANDPLAY and NO_CUSTOM_LEVELS are defined I don't know why you would have to have both defined simultaneously, but now you can. The compile fail was caused by the fact that if both were defined, then there would be an expression like this in Map.cpp: switch (t) { case 0: } which is an invalid expression. The solution is to put 'case 0:' into the MAKEANDPLAY ifdef-guard as well.
2020-04-16 02:52:25 +02:00
case 0:
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 1: //World Map
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tileset = 1;
extrarow = 1;
Change all tilemaps to be short[1200] instead of int[1200] This removes around megabyte from the binary, so a stripped -Og binary went from 4.0 megabytes to 2.9 megabytes, and an unstripped -O0 binary went from 8.1 megabytes to 7.1 megabytes, which means I can now finally upload an unstripped -O0 binary to Discord without having to give money to Discord for their dumb Nitro thing or whatever.
2020-07-19 06:06:35 +02:00
const short* tmap = otherlevel.loadlevel(rx, ry);
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
SDL_memcpy(contents, tmap, sizeof(contents));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = otherlevel.roomname;
tileset = otherlevel.roomtileset;
//do the appear/remove roomname here
Refactor how "hidden names" work By "hidden names", I'm referring to "Dimension VVVVVV" and "The Ship" popping up on the quit/pause/teleporter screens, even though those rooms don't have any roomnames. Apparently my commit to fix roomname re-draw bleed on the quit/pause/teleporter screens exposed yet another hardreset()-caused bug. The issue here is that since hardreset() sets game.roomx and game.roomy to 0, map.area() will no longer work properly, and since the hidden roomname check is based on map.area(), it will no longer display "Dimension VVVVVV" or "The Ship" once you press ACTION to quit. It used to do this due to the re-draw bleed, but now it doesn't. I saw that roomnames didn't get reset in hardreset(), so the solution here is to re-factor hidden names to be an actual variable, instead of being implicit. map.hiddenname is a variable that's set in mapclass::loadlevel(), and if isn't empty, it will be drawn on the quit/pause/teleporter screens. That way it will still display "Dimension VVVVVV" and "The Ship" when you press ACTION to quit to the menu. EDIT: Since PR #230 got merged, this commit is no longer strictly necessary, but it's still good to refactor hidden names like this.
2020-05-02 23:10:22 +02:00
if (game.roomx >= 102 && game.roomx <= 104 && game.roomy >= 110 && game.roomy <= 111)
{
hiddenname = "The Ship";
}
else
{
hiddenname = "Dimension VVVVVV";
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 2: //The Lab
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
{
Change all tilemaps to be short[1200] instead of int[1200] This removes around megabyte from the binary, so a stripped -Og binary went from 4.0 megabytes to 2.9 megabytes, and an unstripped -O0 binary went from 8.1 megabytes to 7.1 megabytes, which means I can now finally upload an unstripped -O0 binary to Discord without having to give money to Discord for their dumb Nitro thing or whatever.
2020-07-19 06:06:35 +02:00
const short* tmap = lablevel.loadlevel(rx, ry);
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
SDL_memcpy(contents, tmap, sizeof(contents));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = lablevel.roomname;
tileset = 1;
background = 2;
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
graphics.rcol = lablevel.rcol;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 3: //The Tower
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
graphics.towerbg.tdrawback = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
minitowermode = false;
tower.minitowermode = false;
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
graphics.towerbg.scrolldir = 0;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = "The Tower";
tileset = 1;
background = 3;
towermode = true;
//All the entities for here are just loaded here; it's essentially one room after all
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(48, 5456, 10, 1, 505007); // (savepoint)
obj.createentity(224, 4528, 10, 1, 505017); // (savepoint)
obj.createentity(232, 4168, 10, 0, 505027); // (savepoint)
obj.createentity(280, 3816, 10, 1, 505037); // (savepoint)
obj.createentity(152, 3552, 10, 1, 505047); // (savepoint)
obj.createentity(216, 3280, 10, 0, 505057); // (savepoint)
obj.createentity(216, 4808, 10, 1, 505067); // (savepoint)
obj.createentity(72, 3096, 10, 0, 505077); // (savepoint)
obj.createentity(176, 2600, 10, 0, 505087); // (savepoint)
obj.createentity(216, 2392, 10, 0, 505097); // (savepoint)
obj.createentity(152, 1184, 10, 1, 505107); // (savepoint)
obj.createentity(152, 912, 10, 1, 505117); // (savepoint)
obj.createentity(152, 536, 10, 1, 505127); // (savepoint)
obj.createentity(120, 5136, 10, 0, 505137); // (savepoint)
obj.createentity(144, 1824, 10, 0, 505147); // (savepoint)
obj.createentity(72, 2904, 10, 0, 505157); // (savepoint)
obj.createentity(224, 1648, 10, 1, 505167); // (savepoint)
obj.createentity(112, 5280, 10, 1, 50517); // (savepoint)
obj.createentity(24, 4216, 9, 7); // (shiny trinket)
obj.createentity(280, 3216, 9, 8); // (shiny trinket)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 4: //The Warpzone
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
{
Change all tilemaps to be short[1200] instead of int[1200] This removes around megabyte from the binary, so a stripped -Og binary went from 4.0 megabytes to 2.9 megabytes, and an unstripped -O0 binary went from 8.1 megabytes to 7.1 megabytes, which means I can now finally upload an unstripped -O0 binary to Discord without having to give money to Discord for their dumb Nitro thing or whatever.
2020-07-19 06:06:35 +02:00
const short* tmap = warplevel.loadlevel(rx, ry);
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
SDL_memcpy(contents, tmap, sizeof(contents));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = warplevel.roomname;
tileset = 1;
background = 3;
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
graphics.rcol = warplevel.rcol;
graphics.backgrounddrawn = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
warpx = warplevel.warpx;
warpy = warplevel.warpy;
background = 5;
if (warpy) background = 4;
if (warpx) background = 3;
if (warpx && warpy) background = 5;
break;
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 5: //Space station
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
{
Change all tilemaps to be short[1200] instead of int[1200] This removes around megabyte from the binary, so a stripped -Og binary went from 4.0 megabytes to 2.9 megabytes, and an unstripped -O0 binary went from 8.1 megabytes to 7.1 megabytes, which means I can now finally upload an unstripped -O0 binary to Discord without having to give money to Discord for their dumb Nitro thing or whatever.
2020-07-19 06:06:35 +02:00
const short* tmap = spacestation2.loadlevel(rx, ry);
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
SDL_memcpy(contents, tmap, sizeof(contents));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = spacestation2.roomname;
tileset = 0;
break;
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 6: //final level
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
{
Remove map.finalx/y and map.customx/y These variables basically serve no purpose. map.customx and map.customy are clearly never used. map.finalx and map.finaly, on the other hand, are basically always game.roomx and game.roomy respectively if map.finalmode is on, and if it's off, then they don't matter. Also, there are some weird and redundant variable assignments going on with these; most notably in map.gotoroom(), where rx/ry (local variables) get assigned to finalx/finaly, then finalx/finaly get assigned to game.roomx/game.roomy, then finalx/finaly get assigned to rx/ry. If finalx/finaly made a difference, then there'd be no need to assign finalx/finaly back to rx/ry. So it makes the code clearer to remove these weird bits of code.
2021-01-11 04:58:36 +01:00
const short* tmap = finallevel.loadlevel(rx, ry);
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
SDL_memcpy(contents, tmap, sizeof(contents));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = finallevel.roomname;
tileset = 1;
background = 3;
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
graphics.backgrounddrawn = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (finalstretch)
{
background = 6;
}
else
{
warpx = finallevel.warpx;
warpy = finallevel.warpy;
background = 5;
if (warpy) background = 4;
if (warpx) background = 3;
if (warpx && warpy) background = 5;
}
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
graphics.rcol = 6;
changefinalcol(final_mapcol);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 7: //Final Level, Tower 1
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
graphics.towerbg.tdrawback = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
minitowermode = true;
tower.minitowermode = true;
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
graphics.towerbg.scrolldir = 1;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = "Panic Room";
tileset = 1;
background = 3;
towermode = true;
tower.loadminitower1();
ypos = 0;
Set map.ypos when entering tower To prevent the camera "zipping" when entering a tower.
2020-04-30 21:02:52 +02:00
oldypos = 0;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
cameramode = 0;
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
graphics.towerbg.colstate = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
colsuperstate = 0;
break;
case 8: //Final Level, Tower 1 (reentered from below)
{
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
graphics.towerbg.tdrawback = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
minitowermode = true;
tower.minitowermode = true;
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
graphics.towerbg.scrolldir = 1;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = "Panic Room";
tileset = 1;
background = 3;
towermode = true;
tower.loadminitower1();
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].yp += (71 * 8);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.roomy--;
ypos = (100-29) * 8;
Set map.ypos when entering tower To prevent the camera "zipping" when entering a tower.
2020-04-30 21:02:52 +02:00
oldypos = ypos;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
cameramode = 0;
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
graphics.towerbg.colstate = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
colsuperstate = 0;}
break;
case 9: //Final Level, Tower 2
{
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
graphics.towerbg.tdrawback = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
minitowermode = true;
tower.minitowermode = true;
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
graphics.towerbg.scrolldir = 0;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = "The Final Challenge";
tileset = 1;
background = 3;
towermode = true;
tower.loadminitower2();
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(56, 556, 11, 136); // (horizontal gravity line)
obj.createentity(184, 592, 10, 0, 50500); // (savepoint)
obj.createentity(184, 644, 11, 88); // (horizontal gravity line)
obj.createentity(56, 460, 11, 136); // (horizontal gravity line)
obj.createentity(216, 440, 10, 0, 50501); // (savepoint)
obj.createentity(104, 508, 11, 168); // (horizontal gravity line)
obj.createentity(219, 264, 12, 56); // (vertical gravity line)
obj.createentity(120, 332, 11, 96); // (horizontal gravity line)
obj.createentity(219, 344, 12, 56); // (vertical gravity line)
obj.createentity(224, 332, 11, 48); // (horizontal gravity line)
obj.createentity(56, 212, 11, 144); // (horizontal gravity line)
obj.createentity(32, 20, 11, 96); // (horizontal gravity line)
obj.createentity(72, 156, 11, 200); // (horizontal gravity line)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01: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].yp += (71 * 8);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.roomy--;
ypos = (100-29) * 8;
Set map.ypos when entering tower To prevent the camera "zipping" when entering a tower.
2020-04-30 21:02:52 +02:00
oldypos = ypos;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
cameramode = 0;
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
graphics.towerbg.colstate = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
colsuperstate = 0;
break;
Fix 'break' statements in other cases not being inside braces It just looks bad visually, so I'm fixing it.
2020-07-09 11:59:42 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 10: //Final Level, Tower 2
{
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
graphics.towerbg.tdrawback = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
minitowermode = true;
tower.minitowermode = true;
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
graphics.towerbg.scrolldir = 0;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = "The Final Challenge";
tileset = 1;
background = 3;
towermode = true;
tower.loadminitower2();
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(56, 556, 11, 136); // (horizontal gravity line)
obj.createentity(184, 592, 10, 0, 50500); // (savepoint)
obj.createentity(184, 644, 11, 88); // (horizontal gravity line)
obj.createentity(56, 460, 11, 136); // (horizontal gravity line)
obj.createentity(216, 440, 10, 0, 50501); // (savepoint)
obj.createentity(104, 508, 11, 168); // (horizontal gravity line)
obj.createentity(219, 264, 12, 56); // (vertical gravity line)
obj.createentity(120, 332, 11, 96); // (horizontal gravity line)
obj.createentity(219, 344, 12, 56); // (vertical gravity line)
obj.createentity(224, 332, 11, 48); // (horizontal gravity line)
obj.createentity(56, 212, 11, 144); // (horizontal gravity line)
obj.createentity(32, 20, 11, 96); // (horizontal gravity line)
obj.createentity(72, 156, 11, 200); // (horizontal gravity line)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
ypos = 0;
Set map.ypos when entering tower To prevent the camera "zipping" when entering a tower.
2020-04-30 21:02:52 +02:00
oldypos = 0;
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
setbgobjlerp(graphics.towerbg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
cameramode = 0;
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
graphics.towerbg.colstate = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
colsuperstate = 0;
break;
Fix 'break' statements in other cases not being inside braces It just looks bad visually, so I'm fixing it.
2020-07-09 11:59:42 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 11: //Tower Hallways //Content is held in final level routine
{
Change all tilemaps to be short[1200] instead of int[1200] This removes around megabyte from the binary, so a stripped -Og binary went from 4.0 megabytes to 2.9 megabytes, and an unstripped -O0 binary went from 8.1 megabytes to 7.1 megabytes, which means I can now finally upload an unstripped -O0 binary to Discord without having to give money to Discord for their dumb Nitro thing or whatever.
2020-07-19 06:06:35 +02:00
const short* tmap = finallevel.loadlevel(rx, ry);
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
SDL_memcpy(contents, tmap, sizeof(contents));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomname = finallevel.roomname;
tileset = 2;
if (rx == 108)
{
background = 7;
rcol = 15;
}
if (rx == 110)
{
background = 8;
rcol = 10;
}
if (rx == 111)
{
background = 9;
rcol = 0;
}
break;
Fix 'break' statements in other cases not being inside braces It just looks bad visually, so I'm fixing it.
2020-07-09 11:59:42 +02:00
}
Fix mixed indentation in Map.h and Map.cpp Again, not that much. These files more-or-less consistently use their respective indentation.
2020-04-02 22:09:22 +02:00
#endif
Add option to allow custom levels when the editor is disabled
2020-02-10 03:21:19 +01:00
#if !defined(NO_CUSTOM_LEVELS)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 12: //Custom level
Add braces to case 12 custom level loading I do this because we declare-and-initialize some variables in the case. This isn't strictly necessary, since there's no cross-initialization errors since it's the last case in the switch, but I'd just like to be future-proof.
2020-07-09 11:58:16 +02:00
{
Refactor room properties to use setter and getter funcs This replaces all raw ed.level accesses with new setter and getter funcs, which makes it easier to add bounds checks later. And I've also removed all the manually-written bounds checks, since they will go into the new getter and setter. To get the room properties of a specific room, you use editorclass::getroomprop(), which returns a pointer to the room properties - then you just read off of that pointer. To set a room property, you use editorclass::setroom<PROP>(), where <PROP> is the name of the property. These are maintained using X macros to avoid copy-pasting. editorclass::getroompropidx() is a helper function and shouldn't be used directly.
2021-03-24 19:59:36 +01:00
const edlevelclass* const room = ed.getroomprop(rx - 100, ry - 100);
game.customcol = ed.getlevelcol(room->tileset, room->tilecol) + 1;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
obj.customplatformtile = game.customcol * 12;
Refactor room properties to use setter and getter funcs This replaces all raw ed.level accesses with new setter and getter funcs, which makes it easier to add bounds checks later. And I've also removed all the manually-written bounds checks, since they will go into the new getter and setter. To get the room properties of a specific room, you use editorclass::getroomprop(), which returns a pointer to the room properties - then you just read off of that pointer. To set a room property, you use editorclass::setroom<PROP>(), where <PROP> is the name of the property. These are maintained using X macros to avoid copy-pasting. editorclass::getroompropidx() is a helper function and shouldn't be used directly.
2021-03-24 19:59:36 +01:00
switch (room->tileset)
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
{
case 0: // Space Station
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tileset = 0;
background = 1;
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 1: // Outside
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tileset = 1;
background = 1;
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 2: // Lab
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tileset = 1;
background = 2;
Refactor room properties to use setter and getter funcs This replaces all raw ed.level accesses with new setter and getter funcs, which makes it easier to add bounds checks later. And I've also removed all the manually-written bounds checks, since they will go into the new getter and setter. To get the room properties of a specific room, you use editorclass::getroomprop(), which returns a pointer to the room properties - then you just read off of that pointer. To set a room property, you use editorclass::setroom<PROP>(), where <PROP> is the name of the property. These are maintained using X macros to avoid copy-pasting. editorclass::getroompropidx() is a helper function and shouldn't be used directly.
2021-03-24 19:59:36 +01:00
graphics.rcol = room->tilecol;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 3: // Warp Zone/intermission
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tileset = 1;
background = 6;
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 4: // Ship
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tileset = 1;
background = 1;
break;
Unindent case labels in room tileset case-switch Again, best practice is to put the case labels on the same indentation level as the switch itself.
2020-07-09 12:18:21 +02:00
default:
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tileset = 1;
background = 1;
break;
}
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
// If screen warping, then override all that:
Don't redraw H/V warp BG if gotorooming to same room in customs This has two benefits: (1) The game uses less resources when it is asked to gotoroom to the same room because it is no longer redrawing the warp background every single frame, which is very wasteful. (2) The warp background no longer freezes or flickers if the player is standing inside a gotoroom script box (which calls gotoroom every frame or every other frame, because every time the gotoroom happens the script box gets reloaded).
2020-01-27 23:46:11 +01:00
bool redrawbg = game.roomx != game.prevroomx || game.roomy != game.prevroomy;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
if (redrawbg)
{
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
graphics.backgrounddrawn = false;
Don't redraw H/V warp BG if gotorooming to same room in customs This has two benefits: (1) The game uses less resources when it is asked to gotoroom to the same room because it is no longer redrawing the warp background every single frame, which is very wasteful. (2) The warp background no longer freezes or flickers if the player is standing inside a gotoroom script box (which calls gotoroom every frame or every other frame, because every time the gotoroom happens the script box gets reloaded).
2020-01-27 23:46:11 +01:00
}
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
Refactor room properties to use setter and getter funcs This replaces all raw ed.level accesses with new setter and getter funcs, which makes it easier to add bounds checks later. And I've also removed all the manually-written bounds checks, since they will go into the new getter and setter. To get the room properties of a specific room, you use editorclass::getroomprop(), which returns a pointer to the room properties - then you just read off of that pointer. To set a room property, you use editorclass::setroom<PROP>(), where <PROP> is the name of the property. These are maintained using X macros to avoid copy-pasting. editorclass::getroompropidx() is a helper function and shouldn't be used directly.
2021-03-24 19:59:36 +01:00
switch (room->warpdir)
Use case-switch for warpdir checking Also, there's no need to put the entire warpdir checking in an 'if(room.warpdir>0)' statement. If any of the cases is jumped to, then you already know that's true.
2020-07-09 12:21:18 +02:00
{
case 1:
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
warpx = true;
background = 3;
graphics.rcol = ed.getwarpbackground(rx - 100, ry - 100);
Use case-switch for warpdir checking Also, there's no need to put the entire warpdir checking in an 'if(room.warpdir>0)' statement. If any of the cases is jumped to, then you already know that's true.
2020-07-09 12:21:18 +02:00
break;
case 2:
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
warpy = true;
background = 4;
graphics.rcol = ed.getwarpbackground(rx - 100, ry - 100);
Use case-switch for warpdir checking Also, there's no need to put the entire warpdir checking in an 'if(room.warpdir>0)' statement. If any of the cases is jumped to, then you already know that's true.
2020-07-09 12:21:18 +02:00
break;
case 3:
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
warpx = true;
warpy = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
background = 5;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
graphics.rcol = ed.getwarpbackground(rx - 100, ry - 100);
Use case-switch for warpdir checking Also, there's no need to put the entire warpdir checking in an 'if(room.warpdir>0)' statement. If any of the cases is jumped to, then you already know that's true.
2020-07-09 12:21:18 +02:00
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Refactor room properties to use setter and getter funcs This replaces all raw ed.level accesses with new setter and getter funcs, which makes it easier to add bounds checks later. And I've also removed all the manually-written bounds checks, since they will go into the new getter and setter. To get the room properties of a specific room, you use editorclass::getroomprop(), which returns a pointer to the room properties - then you just read off of that pointer. To set a room property, you use editorclass::setroom<PROP>(), where <PROP> is the name of the property. These are maintained using X macros to avoid copy-pasting. editorclass::getroompropidx() is a helper function and shouldn't be used directly.
2021-03-24 19:59:36 +01:00
roomname = room->roomname;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
extrarow = 1;
Change all tilemaps to be short[1200] instead of int[1200] This removes around megabyte from the binary, so a stripped -Og binary went from 4.0 megabytes to 2.9 megabytes, and an unstripped -O0 binary went from 8.1 megabytes to 7.1 megabytes, which means I can now finally upload an unstripped -O0 binary to Discord without having to give money to Discord for their dumb Nitro thing or whatever.
2020-07-19 06:06:35 +02:00
const short* tmap = ed.loadlevel(rx, ry);
Turn map.contents into a plain array map.contents always has 1200 tiles in it, there's no reason it should be a vector. This is a big commit because it requires changing all the level classes to return a pointer to an array instead of returning a vector. Which took a while for me to figure out, but eventually I did it. I tested to make sure and there's no problems.
2020-07-03 11:06:46 +02:00
SDL_memcpy(contents, tmap, sizeof(contents));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomtexton = false;
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
roomtext.clear();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
// Entities have to be created HERE, akwardly
int tempcheckpoints = 0;
int tempscriptbox = 0;
for (size_t edi = 0; edi < edentity.size(); edi++)
{
// If entity is in this room, create it
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
const edentities& ent = edentity[edi];
const int tsx = ent.x / 40;
const int tsy = ent.y / 30;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
Negate edentity room check and use a continue This reduces the brace level by one, meaning the indentation level is no longer semi-misleading.
2020-07-09 11:11:56 +02:00
if (tsx != rx-100 || tsy != ry-100)
{
continue;
}
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
const int ex = (ent.x % 40) * 8;
const int ey = (ent.y % 30) * 8;
De-duplicate and add safety check to ed.level reference Instead of repeating 'ed.level[curlevel]' (or even worse, you type in that giant expression inside the brackets instead of reusing 'curlevel'), why not just type 'room'? As an added bonus, I added bounds checks so 'room' is always guaranteed to point to an existing object. There are some levels that index 'ed.level' out of bounds, and I'd like to make their behavior properly defined instead of being undefined. One of the things usually true about out-of-bounds rooms is that they're always tiles2.png (that means an edlevelclass tileset that isn't 0), because the chance of the memory location being exactly 0 is smaller than it being nonzero. So the out-of-bounds room has tileset 1.
2020-07-09 11:54:23 +02:00
De-duplicate enemy/platform bounding box logic It was basically being copy-pasted twice, which isn't good.
2020-07-09 12:06:20 +02:00
// Platform and enemy bounding boxes
Initialize bx1/by1/bx2/by2 in custom entity creation When I compile in release mode, GCC complains that these variables MAY be uninitialized when it comes time to create the moving platform entity. I can't think of any way that it could be uninitialized and testing my release build seemed to be fine, but I'm initializing these variables just to be sure.
2020-08-03 05:43:50 +02:00
int bx1 = 0, by1 = 0, bx2 = 0, by2 = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Fix bounding logic for enemies When I refactored custom level entity creation logic earlier, I forgot to account for enemy bounds, so enemies would take on the same bounds as platforms. But this is fixed now.
2020-08-03 05:47:42 +02:00
bool enemy = ent.t == 1;
bool moving_plat = ent.t == 2 && ent.p1 <= 4;
if (enemy || moving_plat)
De-duplicate enemy/platform bounding box logic It was basically being copy-pasted twice, which isn't good.
2020-07-09 12:06:20 +02:00
{
Fix bounding logic for enemies When I refactored custom level entity creation logic earlier, I forgot to account for enemy bounds, so enemies would take on the same bounds as platforms. But this is fixed now.
2020-08-03 05:47:42 +02:00
if (enemy)
{
Refactor room properties to use setter and getter funcs This replaces all raw ed.level accesses with new setter and getter funcs, which makes it easier to add bounds checks later. And I've also removed all the manually-written bounds checks, since they will go into the new getter and setter. To get the room properties of a specific room, you use editorclass::getroomprop(), which returns a pointer to the room properties - then you just read off of that pointer. To set a room property, you use editorclass::setroom<PROP>(), where <PROP> is the name of the property. These are maintained using X macros to avoid copy-pasting. editorclass::getroompropidx() is a helper function and shouldn't be used directly.
2021-03-24 19:59:36 +01:00
bx1 = room->enemyx1;
by1 = room->enemyy1;
bx2 = room->enemyx2;
by2 = room->enemyy2;
Fix bounding logic for enemies When I refactored custom level entity creation logic earlier, I forgot to account for enemy bounds, so enemies would take on the same bounds as platforms. But this is fixed now.
2020-08-03 05:47:42 +02:00
}
else if (moving_plat)
{
Refactor room properties to use setter and getter funcs This replaces all raw ed.level accesses with new setter and getter funcs, which makes it easier to add bounds checks later. And I've also removed all the manually-written bounds checks, since they will go into the new getter and setter. To get the room properties of a specific room, you use editorclass::getroomprop(), which returns a pointer to the room properties - then you just read off of that pointer. To set a room property, you use editorclass::setroom<PROP>(), where <PROP> is the name of the property. These are maintained using X macros to avoid copy-pasting. editorclass::getroompropidx() is a helper function and shouldn't be used directly.
2021-03-24 19:59:36 +01:00
bx1 = room->platx1;
by1 = room->platy1;
bx2 = room->platx2;
by2 = room->platy2;
Fix bounding logic for enemies When I refactored custom level entity creation logic earlier, I forgot to account for enemy bounds, so enemies would take on the same bounds as platforms. But this is fixed now.
2020-08-03 05:47:42 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
De-duplicate enemy/platform bounding box logic It was basically being copy-pasted twice, which isn't good.
2020-07-09 12:06:20 +02:00
// Enlarge bounding boxes to fix warping entities
if (warpx && bx1 == 0 && bx2 == 320)
{
bx1 -= 100;
bx2 += 100;
}
if (warpy && by1 == 0 && by2 == 240)
{
by1 -= 100;
by2 += 100;
}
}
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
switch (ent.t)
{
case 1: // Enemies
Refactor room properties to use setter and getter funcs This replaces all raw ed.level accesses with new setter and getter funcs, which makes it easier to add bounds checks later. And I've also removed all the manually-written bounds checks, since they will go into the new getter and setter. To get the room properties of a specific room, you use editorclass::getroomprop(), which returns a pointer to the room properties - then you just read off of that pointer. To set a room property, you use editorclass::setroom<PROP>(), where <PROP> is the name of the property. These are maintained using X macros to avoid copy-pasting. editorclass::getroompropidx() is a helper function and shouldn't be used directly.
2021-03-24 19:59:36 +01:00
obj.customenemy = room->enemytype;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
obj.createentity(ex, ey, 56, ent.p1, 4, bx1, by1, bx2, by2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 2: // Platforms and conveyors
if (ent.p1 <= 4)
{
Refactor room properties to use setter and getter funcs This replaces all raw ed.level accesses with new setter and getter funcs, which makes it easier to add bounds checks later. And I've also removed all the manually-written bounds checks, since they will go into the new getter and setter. To get the room properties of a specific room, you use editorclass::getroomprop(), which returns a pointer to the room properties - then you just read off of that pointer. To set a room property, you use editorclass::setroom<PROP>(), where <PROP> is the name of the property. These are maintained using X macros to avoid copy-pasting. editorclass::getroompropidx() is a helper function and shouldn't be used directly.
2021-03-24 19:59:36 +01:00
obj.createentity(ex, ey, 2, ent.p1, room->platv, bx1, by1, bx2, by2);
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
}
else if (ent.p1 >= 5 && ent.p1 <= 8) // Conveyor
{
obj.createentity(ex, ey, 2, ent.p1 + 3, 4);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 3: // Disappearing platforms
De-duplicate expressions of actual coordinates for edentities Previously it copy-pasted this god-awful overcomplicated expression (possibly for cursed ActionScript legacy reasons?) everywhere, instead of putting it in a variable, or even just using a simpler one like the one I replaced it with. Now the obj.createentity() and obj.createblock() calls are much nicer.
2020-07-09 11:28:53 +02:00
obj.createentity(ex, ey, 3);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Fix and update comments for edentities "Threadmills" are now properly called "conveyors". I don't know why they were called "threadmills" anyway, the proper spelling is "treadmills". Also, warp line `p1`s of 0 and 3 are now properly labeled, as well as the trinket edentity.
2020-07-09 12:16:52 +02:00
case 9: // Trinkets
De-duplicate expressions of actual coordinates for edentities Previously it copy-pasted this god-awful overcomplicated expression (possibly for cursed ActionScript legacy reasons?) everywhere, instead of putting it in a variable, or even just using a simpler one like the one I replaced it with. Now the obj.createentity() and obj.createblock() calls are much nicer.
2020-07-09 11:28:53 +02:00
obj.createentity(ex, ey, 9, ed.findtrinket(edi));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 10: // Checkpoints
obj.createentity(ex, ey, 10, ent.p1, (rx + ry*100) * 20 + tempcheckpoints);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tempcheckpoints++;
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 11: // Gravity Lines
if (ent.p1 == 0) //Horizontal
{
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
obj.createentity(ent.p2 * 8, ey + 4, 11, ent.p3);
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
}
else //Vertical
{
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
obj.createentity(ex + 3, ent.p2 * 8, 12, ent.p3);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 13: // Warp Tokens
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
obj.createentity(ex, ey, 13, ent.p1, ent.p2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 15: // Collectable crewmate
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
obj.createentity(ex - 4, ey + 1, 55, ed.findcrewmate(edi), ent.p1, ent.p2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 17: // Roomtext!
Unindent case labels in entity creation Everyone knows that best practice is to put case labels on the same line as the switch statement...
2020-07-09 11:32:52 +02:00
{
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
roomtexton = true;
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
Roomtext text;
De-duplicate expressions of actual coordinates for edentities Previously it copy-pasted this god-awful overcomplicated expression (possibly for cursed ActionScript legacy reasons?) everywhere, instead of putting it in a variable, or even just using a simpler one like the one I replaced it with. Now the obj.createentity() and obj.createblock() calls are much nicer.
2020-07-09 11:28:53 +02:00
text.x = ex / 8;
text.y = ey / 8;
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
text.text = ent.scriptname;
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
roomtext.push_back(text);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Unindent case labels in entity creation Everyone knows that best practice is to put case labels on the same line as the switch statement...
2020-07-09 11:32:52 +02:00
}
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 18: // Terminals
Unindent case labels in entity creation Everyone knows that best practice is to put case labels on the same line as the switch statement...
2020-07-09 11:32:52 +02:00
{
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
obj.customscript = ent.scriptname;
Allow edentity terminals to use any sprite they want Checkpoints can use any sprite they want, why not terminals, too?
2020-07-01 08:43:33 +02:00
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
int usethistile = ent.p1;
De-duplicate expressions of actual coordinates for edentities Previously it copy-pasted this god-awful overcomplicated expression (possibly for cursed ActionScript legacy reasons?) everywhere, instead of putting it in a variable, or even just using a simpler one like the one I replaced it with. Now the obj.createentity() and obj.createblock() calls are much nicer.
2020-07-09 11:28:53 +02:00
int usethisy = ey;
Allow edentity terminals to use any sprite they want Checkpoints can use any sprite they want, why not terminals, too?
2020-07-01 08:43:33 +02:00
// This isn't a boolean: we just swap 0 and 1 around and leave the rest alone
if (usethistile == 0)
{
usethistile = 1; // Unflipped
}
else if (usethistile == 1)
{
usethistile = 0; // Flipped;
usethisy -= 8;
}
De-duplicate expressions of actual coordinates for edentities Previously it copy-pasted this god-awful overcomplicated expression (possibly for cursed ActionScript legacy reasons?) everywhere, instead of putting it in a variable, or even just using a simpler one like the one I replaced it with. Now the obj.createentity() and obj.createblock() calls are much nicer.
2020-07-09 11:28:53 +02:00
obj.createentity(ex, usethisy + 8, 20, usethistile);
Use enum names instead of raw values in createblock() calls It makes it clearer if the enum names are used instead of their values.
2020-07-09 12:10:08 +02:00
obj.createblock(ACTIVITY, ex - 8, usethisy + 8, 20, 16, 35);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Unindent case labels in entity creation Everyone knows that best practice is to put case labels on the same line as the switch statement...
2020-07-09 11:32:52 +02:00
}
case 19: //Script Box
Only set game.customscript if index is inbounds game.customscript is an unnecessary middleman, but it will be kept around for compatibility reasons. However, it's still possible to crash the game, so I'm adding this bounds check.
2020-07-10 08:03:16 +02:00
if (INBOUNDS_ARR(tempscriptbox, game.customscript))
{
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
game.customscript[tempscriptbox] = ent.scriptname;
Only set game.customscript if index is inbounds game.customscript is an unnecessary middleman, but it will be kept around for compatibility reasons. However, it's still possible to crash the game, so I'm adding this bounds check.
2020-07-10 08:03:16 +02:00
}
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
obj.createblock(TRIGGER, ex, ey, ent.p1 * 8, ent.p2 * 8, 300 + tempscriptbox, "custom_" + ent.scriptname);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
tempscriptbox++;
break;
Fix brace style and spacing in custom loadlevel() I don't know who wrote this code originally, but it's extremely obvious that it was a different person than who wrote the rest of the code. Anyway, I fixed the spacing and braces so everything is smushed together less.
2020-07-09 12:29:53 +02:00
case 50: // Warp Lines
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.customwarpmode=true;
Use case-switch for warp line creation No need to repeat the left part of a conditional if we can just use case-switches instead.
2020-07-09 12:14:17 +02:00
switch (ent.p1)
{
Fix and update comments for edentities "Threadmills" are now properly called "conveyors". I don't know why they were called "threadmills" anyway, the proper spelling is "treadmills". Also, warp line `p1`s of 0 and 3 are now properly labeled, as well as the trinket edentity.
2020-07-09 12:16:52 +02:00
case 0: // Vertical, left
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
obj.createentity(ex + 4, ent.p2 * 8, 51, ent.p3);
Use case-switch for warp line creation No need to repeat the left part of a conditional if we can just use case-switches instead.
2020-07-09 12:14:17 +02:00
break;
case 1: //Horizontal, right
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
obj.createentity(ex + 4, ent.p2 * 8, 52, ent.p3);
Use case-switch for warp line creation No need to repeat the left part of a conditional if we can just use case-switches instead.
2020-07-09 12:14:17 +02:00
break;
case 2: //Vertical, top
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
obj.createentity(ent.p2 * 8, ey + 7, 53, ent.p3);
Use case-switch for warp line creation No need to repeat the left part of a conditional if we can just use case-switches instead.
2020-07-09 12:14:17 +02:00
break;
Fix and update comments for edentities "Threadmills" are now properly called "conveyors". I don't know why they were called "threadmills" anyway, the proper spelling is "treadmills". Also, warp line `p1`s of 0 and 3 are now properly labeled, as well as the trinket edentity.
2020-07-09 12:16:52 +02:00
case 3: // Horizontal, bottom
De-duplicate reference to edentity 'edentity[edi]' is a bit long-winded when you really just want to access the attributes of the edentity. How about just 'ent'?
2020-07-09 11:40:18 +02:00
obj.createentity(ent.p2 * 8, ey, 54, ent.p3);
Use case-switch for warp line creation No need to repeat the left part of a conditional if we can just use case-switches instead.
2020-07-09 12:14:17 +02:00
break;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
}
Unindent ending for-loop brace It's rather unnecessary to have it be on the same level as the ending brace for the case-switch.
2020-07-09 11:12:31 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//do the appear/remove roomname here
break;
Add braces to case 12 custom level loading I do this because we declare-and-initialize some variables in the case. This isn't strictly necessary, since there's no cross-initialization errors since it's the last case in the switch, but I'd just like to be future-proof.
2020-07-09 11:58:16 +02:00
}
Add option to compile without the level editor
2020-02-10 01:53:01 +01:00
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
//The room's loaded: now we fill out damage blocks based on the tiles.
if (towermode)
{
Remove outdated comments from Map.cpp Surprisingly not that many. It looks like at one point in development, damage blocks were created for every single spike in the Tower, before it was too laggy so they switched to directly checking collision with the tile instead.
2020-04-03 02:50:13 +02:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
for (int j = 0; j < 29 + extrarow; j++)
{
for (int i = 0; i < 40; i++)
{
//Damage blocks
if(tileset==0)
{
if (contents[i + vmult[j]] == 6 || contents[i + vmult[j]] == 8)
{
//sticking up
obj.createblock(2, (i * 8), (j * 8)+4, 8, 4);
}
if (contents[i + vmult[j]] == 7 || contents[i + vmult[j]] == 9)
{
//Sticking down
obj.createblock(2, (i * 8), (j * 8), 8, 4);
}
if (contents[i + vmult[j]] == 49 || contents[i + vmult[j]] == 50)
{
//left or right
obj.createblock(2, (i * 8), (j * 8)+3, 8, 2);
}
}
else if(tileset==1)
{
//if (contents[i + vmult[j]] >= 6 && contents[i + vmult[j]] <= 9) obj.createblock(2, (i * 8), (j * 8)+1, 8, 6);
//if (contents[i + vmult[j]] >= 49 && contents[i + vmult[j]] <= 79) obj.createblock(2, (i * 8) + 1, (j * 8) + 1, 6, 6);
if ((contents[i + vmult[j]] >= 63 && contents[i + vmult[j]] <= 74) ||
(contents[i + vmult[j]] >= 6 && contents[i + vmult[j]] <= 9))
{
//sticking up) {
if (contents[i + vmult[j]] < 10) contents[i + vmult[j]]++;
//sticking up
if(contents[i + vmult[j]]%2==0)
{
obj.createblock(2, (i * 8), (j * 8), 8, 4);
}
else
{
//Sticking down
obj.createblock(2, (i * 8), (j * 8) + 4, 8, 4);
}
if (contents[i + vmult[j]] < 11) contents[i + vmult[j]]--;
}
if (contents[i + vmult[j]] >= 49 && contents[i + vmult[j]] <= 62)
{
//left or right
obj.createblock(2, (i * 8), (j * 8)+3, 8, 2);
}
}
else if(tileset==2)
{
if (contents[i + vmult[j]] == 6 || contents[i + vmult[j]] == 8)
{
//sticking up
obj.createblock(2, (i * 8), (j * 8)+4, 8, 4);
}
if (contents[i + vmult[j]] == 7 || contents[i + vmult[j]] == 9)
{
//Sticking down
obj.createblock(2, (i * 8), (j * 8), 8, 4);
}
}
//Breakable blocks
if (contents[i + vmult[j]] == 10)
{
contents[i + vmult[j]] = 0;
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(i * 8, j * 8, 4);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
//Directional blocks
if (contents[i + vmult[j]] >= 14 && contents[i + vmult[j]] <= 17)
{
obj.createblock(3, i * 8, j * 8, 8, 8, contents[i + vmult[j]]-14);
}
}
}
Refactor entities and linecrosskludge to not use the 'active' system This removes the variables obj.nentity and obj.nlinecrosskludge, as well as removing the 'active' attribute from the entity class object. Now every entity you access is guaranteed to be real and you don't have to check the 'active' variable. The biggest part of this is changing createentity() to modify a newly-created entity object and push it back instead of already modifying an indice in obj.entities. As well, removing an entity now uses the new obj.removeentity() function and removeentity_iter() macro.
2020-04-03 22:50:16 +02:00
for (size_t i = 0; i < obj.entities.size(); i++)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove remnants of entity 'active' conditionals In the previous commit, if an if-statement consisted solely of checking the active attribute of an entity, I temporarily changed it to 'true' and put a comment to remove it later, because it would add too much noise to unindent everything in the same commit.
2020-04-03 22:57:02 +02:00
if (obj.entities[i].type == 1 && obj.entities[i].behave >= 8 && obj.entities[i].behave < 10)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove remnants of entity 'active' conditionals In the previous commit, if an if-statement consisted solely of checking the active attribute of an entity, I temporarily changed it to 'true' and put a comment to remove it later, because it would add too much noise to unindent everything in the same commit.
2020-04-03 22:57:02 +02:00
//put a block underneath
Move temp and temp2 off of mapclass There's no reason these temporary variables need to exist on the class exist.
2020-07-03 04:20:22 +02:00
int temp = obj.entities[i].xp / 8.0f;
int temp2 = obj.entities[i].yp / 8.0f;
Remove remnants of entity 'active' conditionals In the previous commit, if an if-statement consisted solely of checking the active attribute of an entity, I temporarily changed it to 'true' and put a comment to remove it later, because it would add too much noise to unindent everything in the same commit.
2020-04-03 22:57:02 +02:00
settile(temp, temp2, 1);
settile(temp+1, temp2, 1);
settile(temp+2, temp2, 1);
settile(temp+3, temp2, 1);
if (obj.entities[i].w == 64)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove remnants of entity 'active' conditionals In the previous commit, if an if-statement consisted solely of checking the active attribute of an entity, I temporarily changed it to 'true' and put a comment to remove it later, because it would add too much noise to unindent everything in the same commit.
2020-04-03 22:57:02 +02:00
settile(temp+4, temp2, 1);
settile(temp+5, temp2, 1);
settile(temp+6, temp2, 1);
settile(temp+7, temp2, 1);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
}
//Special scripting: Create objects and triggers based on what crewmembers are rescued.
Prevent spawning crewmates/activity zones in custommode Looks like there wasn't a custommode check for the spawning of crewmates based on which crewmates were rescued, but now there is. This has gone undiscovered for a long time, mostly because people don't use the rescued() internal command.
2020-04-30 08:16:35 +02:00
if (!finalmode && !custommode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//First up: the extra bits:
//Vermilion's quest:
if (rx == 100 && ry == 105) //On path to verdigris
{
if (game.crewstats[3] && !game.crewstats[4])
{
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(87, 105, 18, 15, 0, 18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.createblock(5, 87-32, 0, 32+32+32, 240, 3);
}
}
else if (rx == 107 && ry == 100) //victoria
{
if (game.crewstats[3] && !game.crewstats[5])
{
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(140, 137, 18, 15, 0, 18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.createblock(5, 140-32, 0, 32+32+32, 240, 3);
}
}
else if (rx == 114 && ry == 109)
{
if (game.crewstats[3] && !game.crewstats[2])
{
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(235, 81, 18, 15, 0, 18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.createblock(5, 235-32, 0, 32+32+32, 240, 3);
}
}
//Verdigris fixing the ship
if (rx == 101 && ry == 109)
{
if (game.crewstats[4])
{
if(game.crewrescued()>4 && game.crewrescued()!=6)
{
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(175, 121, 18, 13, 0, 18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.createblock(5, 175-32, 0, 32+32+32, 240, 4);
}
}
}
else if (rx == 103 && ry == 109)
{
if (game.crewstats[4])
{
if(game.crewrescued()<=4 && game.crewrescued()!=6)
{
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(53, 161, 18, 13, 1, 18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.createblock(5, 53-32, 0, 32+32+32, 240, 4);
}
}
}
if (rx == 104 && ry == 111)
{
//Red
//First: is he rescued?
if (game.crewstats[3])
{
//If so, red will always be at his post
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(107, 121, 18, 15, 0, 18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//What script do we use?
obj.createblock(5, 107-32, 0, 32+32+32, 240, 3);
}
}
else if (rx == 103 && ry == 111)
{
//Yellow
//First: is he rescued?
if (game.crewstats[2])
{
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(198, 105, 18, 14, 0, 18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//What script do we use?
obj.createblock(5, 198-32, 0, 32+32+32, 240, 2);
}
}
else if (rx == 103 && ry == 110)
{
//Green
//First: is he rescued?
if (game.crewstats[4])
{
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(242, 177, 18, 13, 0, 18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//What script do we use?
obj.createblock(5, 242-32, 177-20, 32+32+32, 40, 4);
}
}
else if (rx == 104 && ry == 110)
{
//Purple
//First: is she rescued?
if (game.crewstats[1])
{
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(140, 177, 18, 20, 0, 18);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//What script do we use?
obj.createblock(5, 140-32, 0, 32+32+32, 240, 1);
}
}
else if (rx == 102 && ry == 110)
{
//Blue
//First: is she rescued?
if (game.crewstats[5])
{
//A slight varation - she's upside down
Remove global args from entityclass This commit removes all global args from functions on the entityclass object, and updates the callers of those functions in other files accordingly (most significantly, the game level files Finalclass.cpp, Labclass.cpp, Otherlevel.cpp, Spacestation2.cpp, WarpClass.cpp, due to them using createentity()), as well as renaming all instances of 'dwgfx' in Entity.cpp to 'graphics'.
2020-03-31 02:46:36 +02:00
obj.createentity(249, 62, 18, 16, 0, 18);
Remove i/j/k attributes from classes that don't need them The only class that actually needs its i/j/k kept is scriptclass, because some custom levels rely on it for creating custom activity zones. So I haven't touched that. Other than that, there's no chance that anything important relies on i/j/k in any other class. For that to be the case, it would have to use i/j/k without initializing it beforehand, and that can simply be detected by removing the attribute from the header file and seeing where the compiler complains. And the compiler complains only about cases where it's initialized first. (Note that due to this check, I *haven't* removed Graphics's `m` as it precisely does exactly this, using it without initializing it first.) Interestingly enough, otherlevelclass and towerclass have unused i/k variables for whatever reason.
2020-06-14 20:21:32 +02:00
int j = obj.getcrewman(5);
Bounds check all entity getters that can return 0 The entity getters I'm referring to are entityclass::getscm(), entityclass::getlineat(), entityclass::getcrewman(), and entityclass::getcustomcrewman(). Even though the player should always exist, and the player should always be indice 0, I wouldn't want to make that assumption. I've been wrong before. Also, these functions returning 0 lull you into a false sense of security. If you assume that commands using these functions are fine, you'll forget about the fact that `i` in those commands could be potentially anything, given an invalid argument. In fact, it's possible to index createactivityzone(), flipgravity(), and customposition() out-of-bounds by setting `i` to anything! Well, WAS possible. I fixed it so now they can't. Furthermore, in the game.scmmoveme block in gamelogic(), obj.getplayer() wasn't even checked, even though it's been checked in all other places. I only caught it just now because I wanted to bounds-check all usages of obj.getscm(), too, and that game.scmmove block also used obj.getscm() without bounds-checking it as well.
2020-09-10 07:31:09 +02:00
if (INBOUNDS_VEC(j, obj.entities))
{
obj.entities[j].rule = 7;
obj.entities[j].tile +=6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//What script do we use?
obj.createblock(5, 249-32, 0, 32+32+32, 240, 5);
}
}
}
}
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
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 mapclass::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
{
// Fixes the two-frame delay in custom levels that use scripts to spawn an entity upon room load.
// Because when the room loads and newscript is set to run, newscript has already ran for that frame,
// and when the script gets loaded script.run() has already ran for that frame, too.
// A bit kludge-y, but it's the least we can do without changing the frame ordering.
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
if (GlitchrunnerMode_less_than_or_equal(Glitchrunner2_2)
Add custommode check to mapclass::twoframedelayfix() This is to ensure that this function only has an effect inside custom levels. It might do something weird or bad in the main game.
2020-08-17 21:10:22 +02:00
|| !custommode
Move all temporary variables off of entityclass This is a refactor that simply moves all temporary variables off of entityclass, and makes it so they are no longer global variables. This makes the resulting code easier to understand as it is less entangled with global state. These attributes were: - colpoint1 - colpoint2 - tempx - tempy - tempw - temph - temp - temp2 - tpx1 - tpy1 - tpx2 - tpy2 - temprect - temprect2 - x (actually unused) - dx - dy - dr - px - py - linetemp - activetrigger - skipblocks - skipdirblocks Most of these attributes were assigned before any of the times they were used, so it's easy to prove that ungloballing them won't change any behaviors. However, dx, dy, dr, and skipblocks are a bit more tricky to analyze. They relate to blocks, with dx, dy, and dr more specifically relating to one-way tiles. So after some testing with the quirks of one-way tiles, it seems that the jankiness of one-way tiles haven't changed at all, either. Unfortunately, the attribute k is clearly used without being assigned beforehand, so I can't move it off of entityclass. It's the same story with the attribute k that Graphics has, too.
2020-09-26 21:38:57 +02:00
|| game.deathseq != -1)
return;
int block_idx = -1;
// obj.checktrigger() sets block_idx
int activetrigger = obj.checktrigger(&block_idx);
if (activetrigger <= -1
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
|| !INBOUNDS_VEC(block_idx, obj.blocks)
Move all temporary variables off of entityclass This is a refactor that simply moves all temporary variables off of entityclass, and makes it so they are no longer global variables. This makes the resulting code easier to understand as it is less entangled with global state. These attributes were: - colpoint1 - colpoint2 - tempx - tempy - tempw - temph - temp - temp2 - tpx1 - tpy1 - tpx2 - tpy2 - temprect - temprect2 - x (actually unused) - dx - dy - dr - px - py - linetemp - activetrigger - skipblocks - skipdirblocks Most of these attributes were assigned before any of the times they were used, so it's easy to prove that ungloballing them won't change any behaviors. However, dx, dy, dr, and skipblocks are a bit more tricky to analyze. They relate to blocks, with dx, dy, and dr more specifically relating to one-way tiles. So after some testing with the quirks of one-way tiles, it seems that the jankiness of one-way tiles haven't changed at all, either. Unfortunately, the attribute k is clearly used without being assigned beforehand, so I can't move it off of entityclass. It's the same story with the attribute k that Graphics has, too.
2020-09-26 21:38:57 +02:00
|| activetrigger < 300)
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
{
return;
}
Directly execute scripts if script boxes have a non-empty script field Instead of using gamestates, just directly use the 'script' attribute of a script box if it is non-empty. This is accomplished by having to return the index of the block that the player collides with, so callers can inspect the 'script' attribute of the block themselves, and do their logic accordingly.
2020-07-10 08:20:03 +02:00
game.newscript = obj.blocks[block_idx].script;
Move all temporary variables off of entityclass This is a refactor that simply moves all temporary variables off of entityclass, and makes it so they are no longer global variables. This makes the resulting code easier to understand as it is less entangled with global state. These attributes were: - colpoint1 - colpoint2 - tempx - tempy - tempw - temph - temp - temp2 - tpx1 - tpy1 - tpx2 - tpy2 - temprect - temprect2 - x (actually unused) - dx - dy - dr - px - py - linetemp - activetrigger - skipblocks - skipdirblocks Most of these attributes were assigned before any of the times they were used, so it's easy to prove that ungloballing them won't change any behaviors. However, dx, dy, dr, and skipblocks are a bit more tricky to analyze. They relate to blocks, with dx, dy, and dr more specifically relating to one-way tiles. So after some testing with the quirks of one-way tiles, it seems that the jankiness of one-way tiles haven't changed at all, either. Unfortunately, the attribute k is clearly used without being assigned beforehand, so I can't move it off of entityclass. It's the same story with the attribute k that Graphics has, too.
2020-09-26 21:38:57 +02:00
obj.removetrigger(activetrigger);
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
game.state = 0;
game.statedelay = 0;
script.load(game.newscript);
}
Reference in a new issue Copy permalink