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

1780 lines
60 KiB
C++
Raw Normal View History

Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
#include "Credits.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 "Enums.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 "FileSystemUtils.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 "Game.h"
#include "Graphics.h"
#include "Map.h"
#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 "Network.h"
#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"
Fix delta rendering glitch when going to options from new Esc menu Well this is a bit annoying. I can call graphics.updatetowerbackground() just fine, but I have to get at the title color update routine inside titlelogic(), which is hard-baked in. So I have to pull that code outside of the function, export it in the header, and then call it when I transition to TITLEMODE.
2020-06-23 01:41:07 +02:00
void titleupdatetextcol()
{
graphics.col_tr = map.r - (help.glow / 4) - int(fRandom() * 4);
graphics.col_tg = map.g - (help.glow / 4) - int(fRandom() * 4);
graphics.col_tb = map.b - (help.glow / 4) - int(fRandom() * 4);
if (graphics.col_tr < 0) graphics.col_tr = 0;
if(graphics.col_tr>255) graphics.col_tr=255;
if (graphics.col_tg < 0) graphics.col_tg = 0;
if(graphics.col_tg>255) graphics.col_tg=255;
if (graphics.col_tb < 0) graphics.col_tb = 0;
if(graphics.col_tb>255) graphics.col_tb=255;
}
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
void titlelogic()
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Misc
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
//map.updatetowerglow(graphics.titlebg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
help.updateglow();
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.bypos -= 2;
graphics.titlebg.bscroll = -2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Move tower background update code to logic functions Otherwise it'll go really really quickly, which is not good.
2020-04-30 00:25:01 +02:00
if (!game.colourblindmode)
{
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.updatetowerbackground(graphics.titlebg);
Move tower background update code to logic functions Otherwise it'll go really really quickly, which is not good.
2020-04-30 00:25:01 +02:00
}
Fix colors updating too fast in TITLEMODE/MAPMODE/GAMECOMPLETEMODE These colors were of the colors of each crewmate, the inactive crewmate color, and the color of the trinket and clock on the quicksave/summary screens. These colors all used fRandom() and so kept updating too quickly because they would be recalculated every time the delta-timestep render function got called, which isn't ideal. Thus, I've had to add attributes onto the Graphics class to store these colors and make sure they're only recalculated in logic functions instead. Thankfully, the color used for the sprites on the time trial results screen doesn't use fRandom(), so I don't have to worry about those. There's a new version of Graphics::drawsprite() that takes in a pre-made color already, instead of a color ID. As well, I've also added Graphics::updatetitlecolours() to update these colors on the title screen.
2020-05-02 01:40:35 +02:00
if (!game.menustart)
{
graphics.col_tr = (int)(164 - (help.glow / 2) - int(fRandom() * 4));
graphics.col_tg = 164 - (help.glow / 2) - int(fRandom() * 4);
graphics.col_tb = 164 - (help.glow / 2) - int(fRandom() * 4);
}
else
{
Fix delta rendering glitch when going to options from new Esc menu Well this is a bit annoying. I can call graphics.updatetowerbackground() just fine, but I have to get at the title color update routine inside titlelogic(), which is hard-baked in. So I have to pull that code outside of the function, export it in the header, and then call it when I transition to TITLEMODE.
2020-06-23 01:41:07 +02:00
titleupdatetextcol();
Fix colors updating too fast in TITLEMODE/MAPMODE/GAMECOMPLETEMODE These colors were of the colors of each crewmate, the inactive crewmate color, and the color of the trinket and clock on the quicksave/summary screens. These colors all used fRandom() and so kept updating too quickly because they would be recalculated every time the delta-timestep render function got called, which isn't ideal. Thus, I've had to add attributes onto the Graphics class to store these colors and make sure they're only recalculated in logic functions instead. Thankfully, the color used for the sprites on the time trial results screen doesn't use fRandom(), so I don't have to worry about those. There's a new version of Graphics::drawsprite() that takes in a pre-made color already, instead of a color ID. As well, I've also added Graphics::updatetitlecolours() to update these colors on the title screen.
2020-05-02 01:40:35 +02:00
graphics.updatetitlecolours();
}
Move crewframedelay to titlelogic() and maplogic() Incidentally enough, this de-duplicates the amount of times this code has been copy-pasted from 4 times to 2. Anyways, this makes it so the crew don't go lightning fast on the summary screen, the NDM game-over screen, the NDM win screen, and the pause screen in the main game. It was slightly hilarious seeing them go really quickly, actually. It was like they were running away from a giant monster or something.
2020-04-30 02:09:51 +02:00
graphics.crewframedelay--;
if (graphics.crewframedelay <= 0)
{
graphics.crewframedelay = 8;
graphics.crewframe = (graphics.crewframe + 1) % 2;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.menucountdown > 0)
{
game.menucountdown--;
if (game.menucountdown == 0)
{
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
if (game.menudest == Menu::mainmenu)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
music.play(6);
}
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
else if (game.menudest == Menu::gameover2)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(11);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
else if (game.menudest == Menu::timetrialcomplete3)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(3);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't go to main menu when exiting to menu This also replaces some createmenu()s with returnmenu()s as needed even when said createmenu()s already didn't go to the main menu. Now when you exit the level editor, you'll be selecting the "level editor" option in "play levels", and if you exit from a level you'll still be selecting that level in the levels list. Furthermore, regardless of what you're exiting, your cursor position will be remembered.
2020-04-17 06:25:30 +02:00
game.createmenu(game.menudest, true);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
void maplogic()
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Misc
help.updateglow();
Update text boxes in the inner fixed-timestep loop So they don't go really quickly.
2020-04-29 03:38:43 +02:00
graphics.updatetextboxes();
Fix colors updating too fast in TITLEMODE/MAPMODE/GAMECOMPLETEMODE These colors were of the colors of each crewmate, the inactive crewmate color, and the color of the trinket and clock on the quicksave/summary screens. These colors all used fRandom() and so kept updating too quickly because they would be recalculated every time the delta-timestep render function got called, which isn't ideal. Thus, I've had to add attributes onto the Graphics class to store these colors and make sure they're only recalculated in logic functions instead. Thankfully, the color used for the sprites on the time trial results screen doesn't use fRandom(), so I don't have to worry about those. There's a new version of Graphics::drawsprite() that takes in a pre-made color already, instead of a color ID. As well, I've also added Graphics::updatetitlecolours() to update these colors on the title screen.
2020-05-02 01:40:35 +02:00
graphics.updatetitlecolours();
Move menu offset logic to maplogic() This is the logic that handles the timer that brings up and down the teleporter, pause screen, and Esc screen. So now it doesn't go crazy fast.
2020-04-29 05:28:41 +02:00
Move crewframedelay to titlelogic() and maplogic() Incidentally enough, this de-duplicates the amount of times this code has been copy-pasted from 4 times to 2. Anyways, this makes it so the crew don't go lightning fast on the summary screen, the NDM game-over screen, the NDM win screen, and the pause screen in the main game. It was slightly hilarious seeing them go really quickly, actually. It was like they were running away from a giant monster or something.
2020-04-30 02:09:51 +02:00
graphics.crewframedelay--;
if (graphics.crewframedelay <= 0)
{
graphics.crewframedelay = 8;
graphics.crewframe = (graphics.crewframe + 1) % 2;
}
Interpolate bringing up and down quit/pause/teleporter screen Now it's really, really smooth. Except for like the last frame when it goes down, which I sometimes didn't notice (but maybe it didn't happen every time due to being lucky on the delta timesteps or something, whatevs.)
2020-04-29 05:46:33 +02:00
graphics.oldmenuoffset = graphics.menuoffset;
Move menu offset logic to maplogic() This is the logic that handles the timer that brings up and down the teleporter, pause screen, and Esc screen. So now it doesn't go crazy fast.
2020-04-29 05:28:41 +02:00
if (graphics.resumegamemode)
{
graphics.menuoffset += 25;
Simplify menu-off rendering/logic code Since "if (graphics.resumegamemode)" and "if (menuoffset > 0)" both do the same thing, they've been combined with an "or" conjunction. As well, the map.extrarow check in maplogic() has been refactored to use a variable instead of duplicating the entire code block. Not that it matters anyway, because the difference between 240 and 230 is only 10 pixels, far short of the 25 pixel increment that bringing the menu up and down uses, and both 240 and 230 integer-divided by 25 have the same non-remainder value of 9.
2020-04-29 05:31:29 +02:00
int threshold = map.extrarow ? 230 : 240;
if (graphics.menuoffset >= threshold)
Move menu offset logic to maplogic() This is the logic that handles the timer that brings up and down the teleporter, pause screen, and Esc screen. So now it doesn't go crazy fast.
2020-04-29 05:28:41 +02:00
{
Simplify menu-off rendering/logic code Since "if (graphics.resumegamemode)" and "if (menuoffset > 0)" both do the same thing, they've been combined with an "or" conjunction. As well, the map.extrarow check in maplogic() has been refactored to use a variable instead of duplicating the entire code block. Not that it matters anyway, because the difference between 240 and 230 is only 10 pixels, far short of the 25 pixel increment that bringing the menu up and down uses, and both 240 and 230 integer-divided by 25 have the same non-remainder value of 9.
2020-04-29 05:31:29 +02:00
graphics.menuoffset = threshold;
//go back to gamemode!
game.mapheld = true;
game.gamestate = GAMEMODE;
Move menu offset logic to maplogic() This is the logic that handles the timer that brings up and down the teleporter, pause screen, and Esc screen. So now it doesn't go crazy fast.
2020-04-29 05:28:41 +02:00
}
}
else if (graphics.menuoffset > 0)
{
graphics.menuoffset -= 25;
if (graphics.menuoffset < 0)
{
graphics.menuoffset = 0;
}
}
Move cursor delay update logic to maplogic() Otherwise it'll go really really fast. Incidentally this also basically de-duplicates it and results in less copy-pasted code overall.
2020-04-29 06:32:53 +02:00
if (map.cursorstate == 0){
map.cursordelay++;
if (map.cursordelay > 10){
map.cursorstate = 1;
map.cursordelay = 0;
}
}else if (map.cursorstate == 1){
map.cursordelay++;
if (map.cursordelay > 30) map.cursorstate = 2;
}else if (map.cursorstate == 2){
map.cursordelay++;
}
Move glitch roomname updating to logic functions Otherwise they go by so fast that it's basically impossible to see them.
2020-05-02 19:31:48 +02:00
if (map.finalmode)
{
map.glitchname = map.getglitchname(game.roomx, game.roomy);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
void gamecompletelogic()
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Misc
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
map.updatetowerglow(graphics.titlebg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
help.updateglow();
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
graphics.crewframe = 0;
Move title usages of towerbg to titlebg With the previous commit in place, we can now simply move some usages of the previous towerbg to use a separate object instead. That way, we don't have to mess with a monolithic state, or some better way to phrase what I just said, and we instead have two separate objects that can coexist side-by-side.
2020-11-03 00:23:53 +01:00
graphics.titlebg.scrolldir = 1;
Fix colors updating too fast in TITLEMODE/MAPMODE/GAMECOMPLETEMODE These colors were of the colors of each crewmate, the inactive crewmate color, and the color of the trinket and clock on the quicksave/summary screens. These colors all used fRandom() and so kept updating too quickly because they would be recalculated every time the delta-timestep render function got called, which isn't ideal. Thus, I've had to add attributes onto the Graphics class to store these colors and make sure they're only recalculated in logic functions instead. Thankfully, the color used for the sprites on the time trial results screen doesn't use fRandom(), so I don't have to worry about those. There's a new version of Graphics::drawsprite() that takes in a pre-made color already, instead of a color ID. As well, I've also added Graphics::updatetitlecolours() to update these colors on the title screen.
2020-05-02 01:40:35 +02:00
graphics.updatetitlecolours();
graphics.col_tr = map.r - (help.glow / 4) - fRandom() * 4;
graphics.col_tg = map.g - (help.glow / 4) - fRandom() * 4;
graphics.col_tb = map.b - (help.glow / 4) - fRandom() * 4;
if (graphics.col_tr < 0) graphics.col_tr = 0;
if(graphics.col_tr>255) graphics.col_tr=255;
if (graphics.col_tg < 0) graphics.col_tg = 0;
if(graphics.col_tg>255) graphics.col_tg=255;
if (graphics.col_tb < 0) graphics.col_tb = 0;
if(graphics.col_tb>255) graphics.col_tb=255;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.creditposition--;
Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
if (game.creditposition <= -Credits::creditmaxposition)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Turn (super)patrons/githubfriends into arrays & move them to new file So, originally, I wanted to keep them on Game, but it turns out that if I initialize it in Game.cpp, the compiler will complain that other files won't know what's actually inside the array. To do that, I'd have to initialize it in Game.h. But I don't want to initialize it in Game.h because that'd mean recompiling a lot of unnecessary files whenever someone gets added to the credits. So, I moved all the patrons, superpatrons, and GitHub contributors to a new file, Credits.h, which only contains the list (and the credits max position calculation). That way, whenever someone gets added, only the minimal amount of files need to be recompiled.
2020-07-03 12:13:15 +02:00
game.creditposition = -Credits::creditmaxposition;
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.bscroll = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Don't re-draw credits scroll background every frame While I was working on my over-30-FPS patch, I found out that the tower background in the credits scroll was being completely re-drawn every single frame, which was a bit wasteful and expensive. It's also harder to interpolate for my over-30-FPS patch. I'm guessing this constant re-draw was done because the math to get the surface scroll properly working is a bit subtle, but I've figured the precise math out! The first changes of this patch is just removing the unconditional `map.tdrawback = true;`, and having to set `map.scrolldir` everywhere to get the credits scrolling in the right direction but make sure the title screen doesn't start scrolling like a descending tower, too. After that, the first problem is that it looks like the ACTION press to speed up the credits scrolling doesn't speed up the background, too. No problem, just shove a `!game.press_action` check in `gamecompletelogic()`. However, this introduces a mini-problem, which is that NOW when you hold down ACTION, the background appears to be slowly getting out of sync with the credits text by a one-pixel-per-second difference. This is actually due to the fact that, as a result of me adding the conditional, `map.bscroll` is no longer always unconditionally getting set to 1, while `game.creditposition` IS always unconditionally getting decremented by 1. And when you hold down ACTION, `game.creditposition` gets decremented by 6. Thus, I need to set `map.bscroll` when holding down ACTION to be 7, which is 6 plus 1. Then we have another problem, which is that the incoming textures desync when you press ACTION, and when you release ACTION. They desync by precisely 6 pixels, which should be a familiar number. I (eventually) tracked this down to `map.bypos` being updated at the same time `map.bscroll` is, even though `map.bypos` should be updated a frame later AFTER updating `map.bscroll`. So I had to change the `map.bypos` update in `gamecompleteinput()` and `gamecompletelogic()` to be `map.bypos += map.bscroll;` and then place it before any `map.bscroll` update, thus ensuring that `map.bscroll` updates exactly one frame before `map.ypos` does. I had to move the `map.bypos += map.bscroll;` to be in `gamecompleteinput()`, because `gamecompleteinput()` comes first before `gamecompletelogic()` in the `main.cpp` game loop, otherwise the `map.bypos` update won't be delayed by one frame for when you press ACTION to make it go faster, and thus cause a desync when you press ACTION. Oh and then after that, I had to make the descending tower background draw a THIRD row of incoming tiles, otherwise you could see some black flickering at the bottom of the screen when you held down ACTION. All of this took me way too long to figure out, but now the credits scroll works perfectly while being more optimized.
2020-04-30 05:52:33 +02:00
else if (!game.press_action)
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.bscroll = +1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
if (graphics.fademode == 1)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Fix some graphical things
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
graphics.showcutscenebars = false;
graphics.cutscenebarspos = 0;
Interpolate cutscene bars position Cutscene bars will now smoothly fade in and out at above 30 FPS instead of at 30 FPS only.
2020-04-29 02:16:24 +02:00
graphics.oldcutscenebarspos = 0;
Move title usages of towerbg to titlebg With the previous commit in place, we can now simply move some usages of the previous towerbg to use a separate object instead. That way, we don't have to mess with a monolithic state, or some better way to phrase what I just said, and we instead have two separate objects that can coexist side-by-side.
2020-11-03 00:23:53 +01:00
graphics.titlebg.scrolldir = 0;
graphics.titlebg.bypos = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Return to game
Change gamestate ints to their enum names This is to make it easier to read, so I don't have to reference Enums.h if I want to know what they are referring to.
2020-04-17 05:15:53 +02:00
game.gamestate = GAMECOMPLETE2;
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
graphics.fademode = 4;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
void gamecompletelogic2()
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Misc
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
map.updatetowerglow(graphics.titlebg);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
help.updateglow();
game.creditposdelay--;
if (game.creditposdelay <= 0)
{
game.creditposdelay = 1;
game.creditposx++;
if (game.creditposx > 40)
{
game.creditposy++;
game.creditposx = 0;
if (game.creditposy > 30) game.creditposy = 30;
}
}
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
if (graphics.fademode == 1)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Fix some graphical things
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
graphics.showcutscenebars = false;
graphics.cutscenebarspos = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Fix the save thingy
game.deletequick();
int tmp=music.currentsong;
music.currentsong=4;
Fix flag 67 turning on too early Flag 67 seems to be a general-purpose Game Complete flag. It's used to replace the CREW option with the SHIP option on the pause screen. Unfortunately, it gets turned on too early during Game Complete. Right when Viridian starts to teleport, you can bring up the pause screen and select the SHIP option. It will teleport you to the ship coordinates, but still keep you in finalmode, and since the ship coordinates are at 102,111 (finalmode is only around 46,54), you'll still be stuck in Outside Dimension VVVVVV, and you've interrupted the Game Complete gamestate by switching to the teleporting gamestate. Oh, and your checkpoint is set, too, so you can't even press R. Oh and since there's no teleporter, and checkpoint setting doesn't check the sentinel value, this results in Undefined Behavior, too. So this results in an in-game softlock. The only option you can do is quit the game at this point. To fix this issue, just move turning on flag 67 before the savetele() in gamecompletelogic2().
2020-05-09 20:41:54 +02:00
obj.flags[67] = true;
Remove global args from Game I've decided to call dwgfx/game/map/obj/key/help/music the "global args". Because they're essentially global variables that are being passed around in args. This commit removes global args from all functions on the Game class, and deals with updating the callsites of said functions accordingly. It also renames all usages of 'dwgfx' in Game.cpp to 'graphics', since the global variable is called 'graphics' now. Interesting to note, I was removing the class defines from Game.h, but it turns out that Graphics.h depends on the mapclass and entityclass defines from Game.h. And also Graphics.h spelled mapclass wrong (it forgot the "class") so I just decided to use that existing line instead. This is only temporary and after all is said and done, at the end of this pull request those class defines will be gone.
2020-03-31 02:16:02 +02:00
game.savetele();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.currentsong=tmp;
//Return to game
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 = 10;
Change gamestate ints to their enum names This is to make it easier to read, so I don't have to reference Enums.h if I want to know what they are referring to.
2020-04-17 05:15:53 +02:00
game.gamestate = TITLEMODE;
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
graphics.fademode = 4;
Fix custom assets not being unmounted when exiting from editor/credits If you exited from the editor, custom assets would not be unmounted. But I made sure to put the FILESYSTEM_unmountassets() before the music.play(6) because otherwise the menu music wouldn't play. You could also exit to the menu from a custom level using the rollcredits() command, so I made sure to put a FILESYSTEM_unmountassets() when returning to the menu from the credits as well. I also made sure to put it before the music.playef(18) so there's no risk of the sound effect not playing properly, or not playing the non-level-specific one. I added a comment to both FILESYSTEM_unmountasset()s to make sure anyone reading the code is aware of the frame order dependency.
2020-06-17 09:48:10 +02:00
FILESYSTEM_unmountassets(); // should be before music.playef(18)
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(18);
Fix menu that you land on when you complete game or custom level When you complete the game, you're now redirected to the play menu. This is because your quicksave will have been deleted so you can't go back to the summary menu. When you complete a custom level, you'll go back to the levels list, in case you started the level from a quicksave.
2020-05-03 05:38:06 +02:00
game.returntomenu(Menu::play);
Convert menu names to be an enum instead of being stringly-typed Stringly-typed things are bad, because if you make a typo when typing out a string, it's not caught at compile-time. And in the case of this menu system, you'd have to do an excessive amount of testing to uncover any bugs caused by a typo. Why do that when you can just use an enum and catch compile-time errors instead? Also, you can't use switch-case statements on stringly-typed variables. So every menu name is now in the enum Menu::MenuName, but you can simply refer to a menu name by just prefixing it with Menu::. Unfortunately, I've had to change the "continue" menu name to be "continuemenu", because "continue" is a keyword in C and C++. Also, it looks like "timetrialcomplete4" is an unused menu name, even though it was referenced in Render.cpp.
2020-04-16 06:53:36 +02:00
game.createmenu(Menu::gamecompletecontinue);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
map.nexttowercolour();
}
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
void gamelogic()
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Move onground/onroof/animateentities logic to start of gamelogic() For some reason, it was put near the start of gamerender(), even though since it handles edge-flipping it seems like it should be in the logic function already. This makes sure entity animations don't animate as fast as possible, and also fixes edge-flipping on normal surfaces.
2020-04-29 01:25:03 +02:00
if (!game.blackout && !game.completestop)
{
for (size_t i = 0; i < obj.entities.size(); i++)
{
//Is this entity on the ground? (needed for jumping)
if (obj.entitycollidefloor(i))
{
obj.entities[i].onground = 2;
}
else
{
obj.entities[i].onground--;
}
if (obj.entitycollideroof(i))
{
obj.entities[i].onroof = 2;
}
else
{
obj.entities[i].onroof--;
}
//Animate the entities
obj.animateentities(i);
}
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
//Misc
if (map.towermode)
{
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
map.updatetowerglow(graphics.towerbg);
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
help.updateglow();
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (game.alarmon)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
game.alarmdelay--;
if (game.alarmdelay <= 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
music.playef(19);
game.alarmdelay = 20;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (obj.nearelephant)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
obj.upset++;
if (obj.upset == 300)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
obj.upsetmode = true;
//change player to sad
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].tile = 144;
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
music.playef(2);
}
if (obj.upset > 301) obj.upset = 301;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
else if (obj.upsetmode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
obj.upset--;
if (obj.upset <= 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
obj.upset = 0;
obj.upsetmode = false;
//change player to happy
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].tile = 0;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
else
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
obj.upset = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Interpolate trophy text Just to make sure it's extra smooth. Not that it will be noticeable, and you can't access the Secret Lab in slowmode without modifying the game, but it's nice to have this.
2020-04-30 01:54:36 +02:00
obj.oldtrophytext = obj.trophytext;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.towermode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Interpolate tower scrolling Now tower scrolling will look smooth ayy-eff.
2020-04-30 20:52:21 +02:00
map.oldypos = map.ypos;
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
map.oldspikeleveltop = map.spikeleveltop;
map.oldspikelevelbottom = map.spikelevelbottom;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if(!game.completestop)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.cameramode == 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
//do nothing!
//a trigger will set this off in the game
map.cameramode = 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.bscroll = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
else if (map.cameramode == 1)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
//move normally
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(graphics.towerbg.scrolldir==0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
map.ypos -= 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.bypos -= 1;
graphics.towerbg.bscroll = -1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
else
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
map.ypos += 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.bypos += 1;
graphics.towerbg.bscroll = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
else if (map.cameramode == 2)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
//do nothing, but cycle colours (for taking damage)
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.bscroll = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
else if (map.cameramode == 4)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
map.cameraseek = map.ypos - (obj.entities[i].yp - 120);
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
map.cameraseek = map.cameraseek / 10;
map.cameraseekframe = 10;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
map.cameramode = 5;
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.bscroll = map.cameraseek/2;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
}
else if (map.cameramode == 5)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
//actually do it
if (map.spikeleveltop > 0) map.spikeleveltop-=2;
if (map.spikelevelbottom > 0) map.spikelevelbottom-=2;
if (map.cameraseekframe > 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
int i = obj.getplayer();
map.ypos -= map.cameraseek;
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 (map.cameraseek > 0 && INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.ypos < obj.entities[i].yp - 120)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
map.ypos = obj.entities[i].yp - 120;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
else if (INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.ypos > obj.entities[i].yp - 120)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
map.ypos = obj.entities[i].yp - 120;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
map.cameraseekframe--;
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.bypos = map.ypos / 2;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
map.ypos = obj.entities[i].yp - 120;
}
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.bypos = map.ypos / 2;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
map.cameramode = 0;
map.colsuperstate = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
}
else
{
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.bscroll = 0;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.ypos <= 0)
{
map.ypos = 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.bypos = 0;
graphics.towerbg.bscroll = 0;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
}
Add towermode checks to minitowermode screen transitions Apparently, the game just leaves minitowermode on, which can cause issues if you're in a horizontal warping room (and not any other room type, due to how frame ordering works). This would manifest itself as a wrong warp to (20,20) because the game is trying to apply the hardcoded minitower screen transitions when it shouldn't be.
2020-05-05 20:26:26 +02:00
if (map.towermode && map.minitowermode)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
if (map.ypos >= 568)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
map.ypos = 568;
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.bypos = map.ypos / 2;
graphics.towerbg.bscroll = 0;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
} //100-29 * 8 = 568
}
else
{
if (map.ypos >= 5368)
{
map.ypos = 5368; //700-29 * 8 = 5368
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.bypos = map.ypos / 2.0;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (game.lifeseq > 0)
{
if (map.cameramode == 2)
{
map.cameraseekframe = 20;
map.cameramode = 4;
map.resumedelay = 4;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.cameraseekframe <= 0)
{
if (map.resumedelay <= 0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
game.lifesequence();
if (game.lifeseq == 0) map.cameramode = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
map.resumedelay--;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
}
else
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
game.lifesequence();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Fix off-by-one in interpolation of extending gravity line Currently it interpolates it based on the current state of game.swngame, but when game.swngame changes the interpolation doesn't know that it has JUST changed or anything. So add a kludge variable to fix this off-by-one.
2020-05-02 21:06:40 +02:00
graphics.kludgeswnlinewidth = false;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.deathseq != -1)
{
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.towermode)
{
map.colsuperstate = 1;
map.cameramode = 2;
}
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
{
Fix Prize for the Reckless moving platform kludge happening in customs If you died in (11,7) and a moving platform was to the left of the line x=152, even if it was moving vertically it would get snapped to x=152, in custom levels. Surprised nobody has ran into this before (although people have ran into the other kludge, which is placing tile 59 at [18,9] if you're in a room on either the line x=11 or y=7).
2020-02-04 03:53:30 +01:00
if (game.roomx == 111 && game.roomy == 107 && !map.custommode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
if (obj.entities[i].type == 1)
{
if (obj.entities[i].xp < 152)
{
obj.entities[i].xp = 152;
obj.entities[i].newxp = 152;
}
}
}
if (obj.entities[i].type == 2 && obj.entities[i].state == 3)
{
//Ok! super magical exception for the room with the intention death for the shiny trinket
//fix this when the maps are finalised
Fix Prize for the Reckless quicksand fix kludge If you died in Prize for the Reckless, which is at (11,7), and respawned in the same room, tile 59 (a solid invisible tile) would be placed at [18,9] to prevent the moving platform from going back through the quicksand. Unfortunately, the way that this kludge was added is poor. First, the conditional makes it so that it doesn't happen in ONLY (11,7). Instead of being behind a positive conditional, the tile is placed in the else-branch of an if-conditional that checks for the normal case, i.e. if the current room is NOT (11,7), thus being a negative conditional. In other words, the positive conditional is "game.roomx == 111 && game.roomy == 107". To negate it, all you would have to do is "!(game.roomx == 111 && game.roomy == 107)". However, whoever wrote this decided to go one step further, and actually DISTRIBUTE the negative into both statements. This would be fine, except if they actually got it right. You see, according to De Morgan's laws, when you distribute a negative across multiple statements you not only have to negate the statements themselves, but you have to negate all the CONJUNCTIONS, too. In other words, you have to change all "and"s into "or"s and all "or"s into "and"s. Instead of making the conditional "game.roomx != 111 || game.roomy != 107", the person who wrote this forgot to replace the "and" with an "or". Thus, it is "game.roomx != 111 && game.roomy != 107" instead. As a result, if we re-negate this and take a look at the positive conditional, i.e. the conditional that results in the else-branch executing, it turns out to be "game.roomx == 111 || game.roomy == 107". This ends up forming a cross-shape of rooms where this kludge happens. As long as your room is either on the line x=11 or on the line y=7, this kludge will execute. You can see this if you go to Boldly To Go, since it is (11,13), which is on the line x=11. Checkpoint in that room, then touch a disappearing platform, wait for it to fully disappear, then die. Then an invisible tile will be placed to the left of the spikes on the ceiling. Anyway, to fix this, it's simple. Just change the "and" in the negative conditional to an "or". The second problem was that this kludge was happening in custom levels. So I've added a map.custommode check to it. I made sure not to make the same mistake originally made, i.e. I made sure to use an "or" instead of an "and". Thus, when you re-negate the negative conditional and turn it into the positive conditional, it reads: "game.roomx == 111 && game.roomy == 107 && !map.custommode".
2020-02-02 11:26:49 +01:00
if (game.roomx != 111 || game.roomy != 107 || map.custommode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[i].state = 4;
}
else
{
obj.entities[i].state = 4;
map.settile(18, 9, 59);
}
}
else if (obj.entities[i].type == 2 && obj.entities[i].state == 2)
{
//ok, unfortunate case where the disappearing platform hasn't fully disappeared. Accept a little
//graphical uglyness to avoid breaking the room!
Prevent updating an entity if updateentities() removed it Otherwise, this would result in the game updating an entity twice, which isn't good. This is most noticeable in the Gravitron, where many Gravitron squares are created and destroyed at a time, and it's especially noticeable during the part near the end of the Gravitron where the pattern is two Gravitron squares, one at the top and bottom, and then two Gravitron squares in the middle afterwards. The timing is just right such that the top one of the two middle ones would be misaligned with the bottom one of the two when a Gravitron square gets outside the screen. To do this, I changed entityclass::updateentities() into a bool, and made every single caller check its return value. I only needed to do this for the ones preceding updateentitylogic() and entitymapcollision(), but I wanted to play it safe and be defensive, so I did it for the disappearing platform kludge, as well as the updateentities() within the updateentities() function.
2020-05-05 22:49:12 +02:00
bool entitygone = false;
while (obj.entities[i].state == 2)
{
entitygone = obj.updateentities(i);
if (entitygone)
{
i--;
break;
}
}
if (!entitygone) obj.entities[i].state = 4;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (map.finalstretch && obj.entities[i].type == 2)
{
//for the final level. probably something 99% of players won't see.
Prevent updating an entity if updateentities() removed it Otherwise, this would result in the game updating an entity twice, which isn't good. This is most noticeable in the Gravitron, where many Gravitron squares are created and destroyed at a time, and it's especially noticeable during the part near the end of the Gravitron where the pattern is two Gravitron squares, one at the top and bottom, and then two Gravitron squares in the middle afterwards. The timing is just right such that the top one of the two middle ones would be misaligned with the bottom one of the two when a Gravitron square gets outside the screen. To do this, I changed entityclass::updateentities() into a bool, and made every single caller check its return value. I only needed to do this for the ones preceding updateentitylogic() and entitymapcollision(), but I wanted to play it safe and be defensive, so I did it for the disappearing platform kludge, as well as the updateentities() within the updateentities() function.
2020-05-05 22:49:12 +02:00
bool entitygone = false;
while (obj.entities[i].state == 2)
{
entitygone = obj.updateentities(i);
if (entitygone)
{
i--;
break;
}
}
if (!entitygone) obj.entities[i].state = 4;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (obj.entities[i].type == 23 && game.swnmode && game.deathseq<15)
{
//if playing SWN, get the enemies offscreen.
obj.entities[i].xp += obj.entities[i].vx*5;
obj.entities[i].yp += obj.entities[i].vy*5;
}
}
if (game.swnmode)
{
//if playing SWN game a, push the clock back to the nearest 10 second interval
if (game.swngame == 0)
{
game.swnpenalty();
}
else if (game.swngame == 1)
{
game.swnstate = 0;
game.swnstate2 = 0;
game.swnstate3 = 0;
game.swnstate4 = 0;
game.swndelay = 0;
if (game.swntimer >= game.swnrecord)
{
game.swnrecord = game.swntimer;
Don't savestats() every frame of New Record animation Otherwise, this would cause immense slowdown during the New Record animation that plays when you die, as the game would be writing unlock.vvv every frame. To fix this, I just put it under the same if-guard as the music.playef(), since the sound effect also only plays once. But I have to watch out for frame ordering and make sure the record is actually set before I call game.savestats(), and then of course I have to move game.swnmessage = 1 over because that's the variable being checked in the conditional.
2020-07-28 00:50:51 +02:00
if (game.swnmessage == 0)
{
music.playef(25);
game.savestats();
}
game.swnmessage = 1;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
Remove global args from Game I've decided to call dwgfx/game/map/obj/key/help/music the "global args". Because they're essentially global variables that are being passed around in args. This commit removes global args from all functions on the Game class, and deals with updating the callsites of said functions accordingly. It also renames all usages of 'dwgfx' in Game.cpp to 'graphics', since the global variable is called 'graphics' now. Interesting to note, I was removing the class defines from Game.h, but it turns out that Graphics.h depends on the mapclass and entityclass defines from Game.h. And also Graphics.h spelled mapclass wrong (it forgot the "class") so I just decided to use that existing line instead. This is only temporary and after all is said and done, at the end of this pull request those class defines will be gone.
2020-03-31 02:16:02 +02:00
game.deathsequence();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.deathseq--;
if (game.deathseq <= 0)
{
if (game.nodeathmode)
{
game.deathseq = 1;
Remove global args from Game I've decided to call dwgfx/game/map/obj/key/help/music the "global args". Because they're essentially global variables that are being passed around in args. This commit removes global args from all functions on the Game class, and deals with updating the callsites of said functions accordingly. It also renames all usages of 'dwgfx' in Game.cpp to 'graphics', since the global variable is called 'graphics' now. Interesting to note, I was removing the class defines from Game.h, but it turns out that Graphics.h depends on the mapclass and entityclass defines from Game.h. And also Graphics.h spelled mapclass wrong (it forgot the "class") so I just decided to use that existing line instead. This is only temporary and after all is said and done, at the end of this pull request those class defines will be gone.
2020-03-31 02:16:02 +02:00
game.gethardestroom();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//start depressing sequence here...
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
if (game.gameoverdelay <= -10 && graphics.fademode==0) graphics.fademode = 2;
if (graphics.fademode == 1) script.resetgametomenu();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
if (game.swnmode)
{
//if playing SWN game b, reset the clock
if (game.swngame == 1)
{
game.swntimer = 0;
game.swnmessage = 0;
game.swnrank = 0;
}
}
Remove global args from Game I've decided to call dwgfx/game/map/obj/key/help/music the "global args". Because they're essentially global variables that are being passed around in args. This commit removes global args from all functions on the Game class, and deals with updating the callsites of said functions accordingly. It also renames all usages of 'dwgfx' in Game.cpp to 'graphics', since the global variable is called 'graphics' now. Interesting to note, I was removing the class defines from Game.h, but it turns out that Graphics.h depends on the mapclass and entityclass defines from Game.h. And also Graphics.h spelled mapclass wrong (it forgot the "class") so I just decided to use that existing line instead. This is only temporary and after all is said and done, at the end of this pull request those class defines will be gone.
2020-03-31 02:16:02 +02:00
game.gethardestroom();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.hascontrol = true;
game.gravitycontrol = game.savegc;
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
graphics.textboxremove();
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
map.resetplayer();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
else
{
//Update colour thingy
if (map.finalmode)
{
if (map.final_colormode)
{
if (map.final_colorframe > 0)
{
map.final_colorframedelay--;
if (map.final_colorframedelay <= 0)
{
if (map.final_colorframe == 1)
{
map.final_colorframedelay = 40;
Remove global 'temp' variable from titlerender.cpp Just a miscellaneous code cleanup. There's no glitches that take advantage of the previous situation, namely that 'temp' was a global variable in Logic.cpp and editor.cpp. Even if there were, it seems like it would easily lead to some undefined behavior. So it's good to clean this up.
2020-04-03 03:50:37 +02:00
int temp = 1+int(fRandom() * 6);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (temp == map.final_mapcol) temp = (temp + 1) % 6;
if (temp == 0) temp = 6;
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
map.changefinalcol(temp);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else if (map.final_colorframe == 2)
{
map.final_colorframedelay = 15;
Remove global 'temp' variable from titlerender.cpp Just a miscellaneous code cleanup. There's no glitches that take advantage of the previous situation, namely that 'temp' was a global variable in Logic.cpp and editor.cpp. Even if there were, it seems like it would easily lead to some undefined behavior. So it's good to clean this up.
2020-04-03 03:50:37 +02:00
int temp = 1+int(fRandom() * 6);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (temp == map.final_mapcol) temp = (temp + 1) % 6;
if (temp == 0) temp = 6;
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
map.changefinalcol(temp);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
}
}
//State machine for game logic
Remove global args from Game I've decided to call dwgfx/game/map/obj/key/help/music the "global args". Because they're essentially global variables that are being passed around in args. This commit removes global args from all functions on the Game class, and deals with updating the callsites of said functions accordingly. It also renames all usages of 'dwgfx' in Game.cpp to 'graphics', since the global variable is called 'graphics' now. Interesting to note, I was removing the class defines from Game.h, but it turns out that Graphics.h depends on the mapclass and entityclass defines from Game.h. And also Graphics.h spelled mapclass wrong (it forgot the "class") so I just decided to use that existing line instead. This is only temporary and after all is said and done, at the end of this pull request those class defines will be gone.
2020-03-31 02:16:02 +02:00
game.updatestate();
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.startscript)
{
script.load(game.newscript);
game.startscript = false;
}
//Intermission 1 Logic
//Player can't walk off a screen with SCM on it until they've left
if (game.supercrewmate)
{
if (game.roomx == 41 + game.scmprogress) //he's in the same room
{
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities) && obj.entities[i].ax > 0 && obj.entities[i].xp > 280)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[i].ax = 0;
obj.entities[i].dir = 0;
}
}
}
//SWN Minigame Logic
if (game.swnmode) //which game?
{
if(game.swngame==0) //intermission, survive 60 seconds game
{
game.swntimer -= 1;
if (game.swntimer <= 0)
{
music.niceplay(8);
game.swngame = 5;
}
else
{
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.generateswnwave(0);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else if(game.swngame==1) //super gravitron game
{
game.swntimer += 1;
if (game.swntimer > game.swnrecord) game.swnrecord = game.swntimer;
if (game.swntimer >= 150 && game.swnrank == 0)
{
game.swnrank = 1;
if (game.swnbestrank < 1)
{
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
game.unlockAchievement("vvvvvvsupgrav5");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.swnbestrank = 1;
game.swnmessage = 2+30;
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(26);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else if (game.swntimer >= 300 && game.swnrank == 1)
{
game.swnrank = 2;
if (game.swnbestrank < 2)
{
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
game.unlockAchievement("vvvvvvsupgrav10");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.swnbestrank = 2;
game.swnmessage = 2+30;
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(26);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else if (game.swntimer >= 450 && game.swnrank == 2)
{
game.swnrank = 3;
if (game.swnbestrank < 3)
{
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
game.unlockAchievement("vvvvvvsupgrav15");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.swnbestrank = 3;
game.swnmessage = 2+30;
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(26);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else if (game.swntimer >= 600 && game.swnrank == 3)
{
game.swnrank = 4;
if (game.swnbestrank < 4)
{
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
game.unlockAchievement("vvvvvvsupgrav20");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.swnbestrank = 4;
game.swnmessage = 2+30;
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(26);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else if (game.swntimer >= 900 && game.swnrank == 4)
{
game.swnrank = 5;
if (game.swnbestrank < 5)
{
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
game.unlockAchievement("vvvvvvsupgrav30");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.swnbestrank = 5;
game.swnmessage = 2+30;
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(26);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else if (game.swntimer >= 1800 && game.swnrank == 5)
{
game.swnrank = 6;
if (game.swnbestrank < 6)
{
Fix #380 Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false. Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 21:49:07 +02:00
game.unlockAchievement("vvvvvvsupgrav60");
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.swnbestrank = 6;
game.swnmessage = 2+30;
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(26);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
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.generateswnwave(1);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.swncoldelay--;
if(game.swncoldelay<=0)
{
game.swncolstate = (game.swncolstate+1)%6;
game.swncoldelay = 30;
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
graphics.rcol = game.swncolstate;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
obj.swnenemiescol(game.swncolstate);
}
}
else if (game.swngame == 2) //introduce game a
{
game.swndelay--;
if (game.swndelay <= 0)
{
game.swngame = 0;
game.swndelay = 0;
game.swntimer = (60 * 30) - 1;
//game.swntimer = 15;
}
}
else if (game.swngame == 3) //extend line
{
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
int line = obj.getlineat(84 - 32);
if (INBOUNDS_VEC(line, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
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
obj.entities[line].w += 24;
if (obj.entities[line].w > 332)
{
obj.entities[line].w = 332;
game.swngame = 2;
graphics.kludgeswnlinewidth = true;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else if (game.swngame == 4) //create top line
{
game.swngame = 3;
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(-8, 84 - 32, 11, 8); // (horizontal gravity line)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
music.niceplay(2);
game.swndeaths = game.deathcounts;
}
else if (game.swngame == 5) //remove line
{
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
int line = obj.getlineat(148 + 32);
if (INBOUNDS_VEC(line, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
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
obj.entities[line].xp += 24;
if (obj.entities[line].xp > 320)
{
obj.removeentity(line);
game.swnmode = false;
game.swngame = 6;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else if (game.swngame == 6) //Init the super gravitron
{
game.swngame = 7;
music.niceplay(3);
}
else if (game.swngame == 7) //introduce game b
{
game.swndelay--;
if (game.swndelay <= 0)
{
game.swngame = 1;
game.swndelay = 0;
game.swntimer = 0;
game.swncolstate = 3;
game.swncoldelay = 30;
}
}
}
//Time trial stuff
if (game.intimetrial)
{
if (game.timetrialcountdown > 0)
{
game.timetrialparlost = false;
game.hascontrol = true;
game.timetrialcountdown--;
if (game.timetrialcountdown > 30)
{
game.hascontrol = false;
}
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
if(game.timetrialcountdown == 120) music.playef(21);
if(game.timetrialcountdown == 90) music.playef(21);
if(game.timetrialcountdown == 60) music.playef(21);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.timetrialcountdown == 30)
{
switch(game.timetriallevel)
{
case 0:
music.play(1);
break;
case 1:
music.play(3);
break;
case 2:
music.play(2);
break;
case 3:
music.play(1);
break;
case 4:
music.play(12);
break;
case 5:
music.play(15);
break;
}
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(22);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
//Have we lost the par?
if (!game.timetrialparlost)
{
if ((game.minutes * 60) + game.seconds > game.timetrialpar)
{
game.timetrialparlost = true;
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].tile = 144;
}
Remove unused argument from musicclass::playef() Apparently the 'offset' argument did something in the 1.x Flash versions, but now it does nothing.
2020-04-02 01:36:35 +02:00
music.playef(2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
//Update entities
//Ok, moving platform fuckers
if(!game.completestop)
{
if(obj.vertplatforms)
{
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 (int i = obj.entities.size() - 1; i >= 0; i--)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Collapse and invert if-statements in entity logic loops This makes the code easier to read by reducing the amount of indentation it has.
2020-10-07 01:15:44 +02:00
if (!obj.entities[i].isplatform
|| SDL_abs(obj.entities[i].vx) >= 0.000001f)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Collapse and invert if-statements in entity logic loops This makes the code easier to read by reducing the amount of indentation it has.
2020-10-07 01:15:44 +02:00
continue;
}
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
int prevx = obj.entities[i].xp;
int prevy = obj.entities[i].yp;
obj.nocollisionat(prevx, prevy);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unindent entity update loops from previous commit This unindent is done in a separate commit to minimize diff noise.
2020-10-07 01:16:48 +02:00
bool entitygone = obj.updateentities(i); // Behavioral logic
if (entitygone) continue;
obj.updateentitylogic(i); // Basic Physics
obj.entitymapcollision(i); // Collisions with walls
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
obj.moveblockto(prevx, prevy, obj.entities[i].xp, obj.entities[i].yp, obj.entities[i].w, obj.entities[i].h);
Unindent entity update loops from previous commit This unindent is done in a separate commit to minimize diff noise.
2020-10-07 01:16:48 +02:00
obj.movingplatformfix(i, obj.getplayer());
if (game.supercrewmate)
{
obj.movingplatformfix(i, obj.getscm());
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
if(obj.horplatforms)
{
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 (int ie = obj.entities.size() - 1; ie >= 0; ie--)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Collapse and invert if-statements in entity logic loops This makes the code easier to read by reducing the amount of indentation it has.
2020-10-07 01:15:44 +02:00
if (!obj.entities[ie].isplatform
|| SDL_abs(obj.entities[ie].vy) >= 0.000001f)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Collapse and invert if-statements in entity logic loops This makes the code easier to read by reducing the amount of indentation it has.
2020-10-07 01:15:44 +02:00
continue;
}
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
int prevx = obj.entities[ie].xp;
int prevy = obj.entities[ie].yp;
obj.nocollisionat(prevx, prevy);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Unindent entity update loops from previous commit This unindent is done in a separate commit to minimize diff noise.
2020-10-07 01:16:48 +02:00
bool entitygone = obj.updateentities(ie); // Behavioral logic
if (entitygone) continue;
obj.updateentitylogic(ie); // Basic Physics
obj.entitymapcollision(ie); // Collisions with walls
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
obj.moveblockto(prevx, prevy, obj.entities[ie].xp, obj.entities[ie].yp, obj.entities[ie].w, obj.entities[ie].h);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
//is the player standing on a moving platform?
int i = obj.getplayer();
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
float j = obj.entitycollideplatformfloor(i);
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) && j > -1000)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[i].newxp = obj.entities[i].xp + j;
Fix glitchy y-position when colliding with a conveyor There is this issue with conveyors where if you collide with them, your intended next y-position doesn't get updated to the position of the conveyor, and then your y-position gets set to your intended next y-position. This also applies to horizontally moving platforms. This bug used to not produce any problems, if at all, until #502 got merged. Since then, respawning from checkpoints that are on conveyors would sometimes not update your y-position at all, making it possible to get stuck inside a death loop that would require you to exit the game and re-enter it. But you can always reliably create this bug simply by going into the editor and placing down a conveyor and checkpoint on top of each other. Then enter and exit playtesting a bunch of times, and you'll notice the glitchy y-position Viridian keeps taking on. The root cause of this is how the game moves the player whenever they stand on the top or bottom of a conveyor (or a horizontally moving platform). The game sets their intended next x-position (newxp), then calls obj.entitymapcollision() on them. This would be okay, except their intended next y-position (newyp) doesn't get set along with their newxp, so entitymapcollision() will use the wrong newyp, then find that there is nothing that will collide with the player at that given newyp, then update the yp of the player to the wrong newyp. So, the platform logic simply doesn't set the player's newyp. Why does the player have the wrong newyp? It's because moving platforms (and conveyors) are updated first before all other entities are, and this includes the code that checks the player for collisions with moving platforms. That's right: the moving platform collision code gets ran before the player properly gets updated. This means that the game will use the newyp of the previous frame, which could be anything, really, but it most likely just means the intended next y-position of the player gets canceled, leaving the player with the same y-position they had before. Okay, but this bug only seems to happen when you put a checkpoint inside a conveyor (or a moving platform that hasn't started moving yet) and start playtesting from it, so why doesn't this bug happen more often, then? Well, it's probably because of luck and coincidence. Most of the time, if you're colliding with a conveyor or horizontally moving platform, you probably have a correct newyp from the previous frame of the game, so there'd be no problems. And before #502 got merged, this previous frame would be provided by the player having to fall to the surface due to the y-offset of their savepoint. However, if you make it so that you immediately teleport on to a conveyor (because you died), then this bug will rear its ugly head.
2020-10-31 19:52:06 +01:00
obj.entities[i].newyp = obj.entities[i].yp;
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.entitymapcollision(i);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
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
j = obj.entitycollideplatformroof(i);
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) && j > -1000)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[i].newxp = obj.entities[i].xp + j;
Fix glitchy y-position when colliding with a conveyor There is this issue with conveyors where if you collide with them, your intended next y-position doesn't get updated to the position of the conveyor, and then your y-position gets set to your intended next y-position. This also applies to horizontally moving platforms. This bug used to not produce any problems, if at all, until #502 got merged. Since then, respawning from checkpoints that are on conveyors would sometimes not update your y-position at all, making it possible to get stuck inside a death loop that would require you to exit the game and re-enter it. But you can always reliably create this bug simply by going into the editor and placing down a conveyor and checkpoint on top of each other. Then enter and exit playtesting a bunch of times, and you'll notice the glitchy y-position Viridian keeps taking on. The root cause of this is how the game moves the player whenever they stand on the top or bottom of a conveyor (or a horizontally moving platform). The game sets their intended next x-position (newxp), then calls obj.entitymapcollision() on them. This would be okay, except their intended next y-position (newyp) doesn't get set along with their newxp, so entitymapcollision() will use the wrong newyp, then find that there is nothing that will collide with the player at that given newyp, then update the yp of the player to the wrong newyp. So, the platform logic simply doesn't set the player's newyp. Why does the player have the wrong newyp? It's because moving platforms (and conveyors) are updated first before all other entities are, and this includes the code that checks the player for collisions with moving platforms. That's right: the moving platform collision code gets ran before the player properly gets updated. This means that the game will use the newyp of the previous frame, which could be anything, really, but it most likely just means the intended next y-position of the player gets canceled, leaving the player with the same y-position they had before. Okay, but this bug only seems to happen when you put a checkpoint inside a conveyor (or a moving platform that hasn't started moving yet) and start playtesting from it, so why doesn't this bug happen more often, then? Well, it's probably because of luck and coincidence. Most of the time, if you're colliding with a conveyor or horizontally moving platform, you probably have a correct newyp from the previous frame of the game, so there'd be no problems. And before #502 got merged, this previous frame would be provided by the player having to fall to the surface due to the y-offset of their savepoint. However, if you make it so that you immediately teleport on to a conveyor (because you died), then this bug will rear its ugly head.
2020-10-31 19:52:06 +01:00
obj.entities[i].newyp = obj.entities[i].yp;
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.entitymapcollision(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
for (int ie = obj.entities.size() - 1; ie >= 0; ie--)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Collapse and invert if-statements in entity logic loops This makes the code easier to read by reducing the amount of indentation it has.
2020-10-07 01:15:44 +02:00
if (obj.entities[ie].isplatform)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Collapse and invert if-statements in entity logic loops This makes the code easier to read by reducing the amount of indentation it has.
2020-10-07 01:15:44 +02:00
continue;
}
Unindent entity update loops from previous commit This unindent is done in a separate commit to minimize diff noise.
2020-10-07 01:16:48 +02:00
bool entitygone = obj.updateentities(ie); // Behavioral logic
if (entitygone) continue;
obj.updateentitylogic(ie); // Basic Physics
obj.entitymapcollision(ie); // Collisions with walls
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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.entitycollisioncheck(); // Check ent v ent collisions, update states
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.towermode)
{
//special for tower: is the player touching any spike blocks?
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) && obj.checktowerspikes(player) && graphics.fademode==0)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
game.deathseq = 30;
}
}
if(map.towermode && game.lifeseq==0)
{
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(!map.invincibility && INBOUNDS_VEC(player, obj.entities))
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
if (obj.entities[player].yp-map.ypos <= 0)
{
game.deathseq = 30;
}
else if (obj.entities[player].yp-map.ypos >= 208)
{
game.deathseq = 30;
}
}
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
else if (INBOUNDS_VEC(player, obj.entities))
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
if (obj.entities[player].yp-map.ypos <= 0)
{
map.ypos-=10;
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.bypos = map.ypos / 2;
graphics.towerbg.bscroll = 0;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
}
else if (obj.entities[player].yp-map.ypos >= 208)
{
map.ypos+=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.bypos = map.ypos / 2;
graphics.towerbg.bscroll = 0;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
}
}
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(player, obj.entities) && obj.entities[player].yp - map.ypos <= 40)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
map.spikeleveltop++;
if (map.spikeleveltop >= 8) map.spikeleveltop = 8;
}
else
{
if (map.spikeleveltop > 0) map.spikeleveltop--;
}
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) && obj.entities[player].yp - map.ypos >= 164)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
map.spikelevelbottom++;
if (map.spikelevelbottom >= 8) map.spikelevelbottom = 8;
}
else
{
if (map.spikelevelbottom > 0) map.spikelevelbottom--;
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
//Using warplines?
Fix mixed indentation in Logic.cpp It's clear that there was another person who added achievements and did some warp line stuff.
2020-04-02 22:44:45 +02:00
if (obj.customwarpmode) {
Restore pre-2.1 warp bypass glitch in glitchrunner mode So, I was staring at VVVVVV code one day, as I usually do, and I noticed that warp lines had this curious code in entityclass::updateentities() that set their statedelay to 2, and I thought, hm, maybe the pre-2.1 warp line bypass is caused by this statedelay. And, it doesn't seem like this is the primary code used to detect if the player collides with warp lines, the actual code is commented with "Rewritten system for mobile update" and bolted-on in gamelogic() instead of properly being in entityclass::entitycollisioncheck(). So, after getting tripped up on the misleading indentation of that "Rewritten system" block, I removed the rewritten system, re-added collision detection for rule 7 (horizontal warp lines), and after checking the resulting behavior, it appears to be nearly identical to that of warp lines in 2.0. You see, if you use warp lines to flip up from the top of the screen onto the bottom of the screen, close to the edge of the bottom of the screen, Viridian's head will display on the top of the screen in 2.0. In 2.1 and later, this doesn't happen, confirming that my theory is correct. I also performed warp line bypass multiple times in 2.0 and with my restored code, and it is pretty much the exact same behavior. So now, the pre-2.1 warp line bypass glitch has been re-enabled in glitchrunner mode.
2020-09-10 01:10:16 +02:00
if (!game.glitchrunnermode) {
//Rewritten system for mobile update: basically, the new logic is to
//check if the player is leaving the map, and if so do a special check against
//warp lines for collision
obj.customwarpmodehon = false;
obj.customwarpmodevon = false;
Fix mixed indentation in Logic.cpp It's clear that there was another person who added achievements and did some warp line stuff.
2020-04-02 22:44:45 +02:00
Restore pre-2.1 warp bypass glitch in glitchrunner mode So, I was staring at VVVVVV code one day, as I usually do, and I noticed that warp lines had this curious code in entityclass::updateentities() that set their statedelay to 2, and I thought, hm, maybe the pre-2.1 warp line bypass is caused by this statedelay. And, it doesn't seem like this is the primary code used to detect if the player collides with warp lines, the actual code is commented with "Rewritten system for mobile update" and bolted-on in gamelogic() instead of properly being in entityclass::entitycollisioncheck(). So, after getting tripped up on the misleading indentation of that "Rewritten system" block, I removed the rewritten system, re-added collision detection for rule 7 (horizontal warp lines), and after checking the resulting behavior, it appears to be nearly identical to that of warp lines in 2.0. You see, if you use warp lines to flip up from the top of the screen onto the bottom of the screen, close to the edge of the bottom of the screen, Viridian's head will display on the top of the screen in 2.0. In 2.1 and later, this doesn't happen, confirming that my theory is correct. I also performed warp line bypass multiple times in 2.0 and with my restored code, and it is pretty much the exact same behavior. So now, the pre-2.1 warp line bypass glitch has been re-enabled in glitchrunner mode.
2020-09-10 01:10:16 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities) && ((game.door_down > -2 && obj.entities[i].yp >= 226-16) || (game.door_up > -2 && obj.entities[i].yp < -2+16) || (game.door_left > -2 && obj.entities[i].xp < -14+16) || (game.door_right > -2 && obj.entities[i].xp >= 308-16))){
Restore pre-2.1 warp bypass glitch in glitchrunner mode So, I was staring at VVVVVV code one day, as I usually do, and I noticed that warp lines had this curious code in entityclass::updateentities() that set their statedelay to 2, and I thought, hm, maybe the pre-2.1 warp line bypass is caused by this statedelay. And, it doesn't seem like this is the primary code used to detect if the player collides with warp lines, the actual code is commented with "Rewritten system for mobile update" and bolted-on in gamelogic() instead of properly being in entityclass::entitycollisioncheck(). So, after getting tripped up on the misleading indentation of that "Rewritten system" block, I removed the rewritten system, re-added collision detection for rule 7 (horizontal warp lines), and after checking the resulting behavior, it appears to be nearly identical to that of warp lines in 2.0. You see, if you use warp lines to flip up from the top of the screen onto the bottom of the screen, close to the edge of the bottom of the screen, Viridian's head will display on the top of the screen in 2.0. In 2.1 and later, this doesn't happen, confirming that my theory is correct. I also performed warp line bypass multiple times in 2.0 and with my restored code, and it is pretty much the exact same behavior. So now, the pre-2.1 warp line bypass glitch has been re-enabled in glitchrunner mode.
2020-09-10 01:10:16 +02:00
//Player is leaving room
obj.customwarplinecheck(i);
}
Fix misleading indentation in obj.customwarpmode block This misleading indentation makes it really easy to misanalyze this block as only containing the statements up to obj.customwarplinecheck(), when in reality it contains everything up to the modifying of map.warpx/map.warpy. I have made this misanalysis just now in my attempt to figure out the pre-2.1 warp line bypass glitch, and I don't like it. So I'm fixing this indentation now.
2020-09-10 00:45:03 +02:00
}
Fix mixed indentation in Logic.cpp It's clear that there was another person who added achievements and did some warp line stuff.
2020-04-02 22:44:45 +02:00
Fix misleading indentation in obj.customwarpmode block This misleading indentation makes it really easy to misanalyze this block as only containing the statements up to obj.customwarplinecheck(), when in reality it contains everything up to the modifying of map.warpx/map.warpy. I have made this misanalysis just now in my attempt to figure out the pre-2.1 warp line bypass glitch, and I don't like it. So I'm fixing this indentation now.
2020-09-10 00:45:03 +02:00
if(obj.customwarpmodehon){ map.warpy=true;
}else{ map.warpy=false; }
if(obj.customwarpmodevon){ map.warpx=true;
}else{ map.warpx=false; }
Fix mixed indentation in Logic.cpp It's clear that there was another person who added achievements and did some warp line stuff.
2020-04-02 22:44:45 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Finally: Are we changing room?
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.warpx && !map.towermode)
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
{
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
if(obj.entities[i].type<50 //Don't warp warp lines
&& obj.entities[i].size < 12) //Don't wrap SWN enemies
{
if (game.roomx == 118 && game.roomy == 102 && obj.entities[i].rule==1 && !map.custommode)
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
{
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
//ascii snakes
if (obj.entities[i].xp <= -80)
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
{
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
if (obj.entities[i].isplatform)
{
obj.moveblockto(obj.entities[i].xp, obj.entities[i].yp, obj.entities[i].xp + 400, obj.entities[i].yp, obj.entities[i].w, obj.entities[i].h);
}
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
obj.entities[i].xp += 400;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp += 400;
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
}
Condense some nested else-if statements It's better to write 'else if' than 'else { if }'.
2020-04-04 21:19:18 +02:00
else if (obj.entities[i].xp > 320)
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
{
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
if (obj.entities[i].isplatform)
{
obj.moveblockto(obj.entities[i].xp, obj.entities[i].yp, obj.entities[i].xp - 400, obj.entities[i].yp, obj.entities[i].w, obj.entities[i].h);
}
Condense some nested else-if statements It's better to write 'else if' than 'else { if }'.
2020-04-04 21:19:18 +02:00
obj.entities[i].xp -= 400;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp -= 400;
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
}
}
else
{
if (obj.entities[i].xp <= -10)
{
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
if (obj.entities[i].isplatform)
{
obj.moveblockto(obj.entities[i].xp, obj.entities[i].yp, obj.entities[i].xp + 320, obj.entities[i].yp, obj.entities[i].w, obj.entities[i].h);
}
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
obj.entities[i].xp += 320;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp += 320;
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
}
Condense some nested else-if statements It's better to write 'else if' than 'else { if }'.
2020-04-04 21:19:18 +02:00
else if (obj.entities[i].xp > 310)
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
{
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
if (obj.entities[i].isplatform)
{
obj.moveblockto(obj.entities[i].xp, obj.entities[i].yp, obj.entities[i].xp - 320, obj.entities[i].yp, obj.entities[i].w, obj.entities[i].h);
}
Condense some nested else-if statements It's better to write 'else if' than 'else { if }'.
2020-04-04 21:19:18 +02:00
obj.entities[i].xp -= 320;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp -= 320;
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
De-dupe screen transition / warping logic I noticed that the code for going to the adjacent room when offscreen and for warping instead if the room is warping was a bit copy-and-pasted. To clean up the code a bit, there's now 5 separate checks in gamelogic(): if (map.warpx) if (map.warpy) if (map.warpy && !map.warpx) if (!map.warpy) if (!map.warpx) I made sure to preserve the previous weird horizontal warping behavior that happens with vertical warping (thus the middle one), and to preserve the frame ordering just in case there's something dependent on the frame ordering. The frame ordering is that first it will warp you horizontally, if applicable, then it will warp you vertically, if applicable. Then if you have vertical warping only, that weird horizontal warp. Then it will screen transition you vertically, if applicable. Then it will screen transition you horizontally, if applicable. To explain the weird horizontal warp with the vertical warp: apparently if an entity is far offscreen enough, and if that entity is not the player, it will be warped horizontally during a vertical warp. The points at which it will warp is 30 pixels farther out than normal horizontal warping. I think someone ran into this before, but my memory is fuzzy. The best I can recall is that they were probably createentity()ing a high-speed horizontally-moving enemy in a vertically warping room, only to discover that said enemy kept warping horizontally.
2020-04-04 21:39:17 +02:00
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.warpy && !map.towermode)
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
{
if(obj.entities[i].type<50){ //Don't warp warp lines
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
if (obj.entities[i].yp <= -12)
{
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
if (obj.entities[i].isplatform)
{
obj.moveblockto(obj.entities[i].xp, obj.entities[i].yp, obj.entities[i].xp, obj.entities[i].yp + 232, obj.entities[i].w, obj.entities[i].h);
}
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
obj.entities[i].yp += 232;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldyp += 232;
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
}
Condense some nested else-if statements It's better to write 'else if' than 'else { if }'.
2020-04-04 21:19:18 +02:00
else if (obj.entities[i].yp > 226)
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
{
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
if (obj.entities[i].isplatform)
{
obj.moveblockto(obj.entities[i].xp, obj.entities[i].yp, obj.entities[i].xp, obj.entities[i].yp - 232, obj.entities[i].w, obj.entities[i].h);
}
Condense some nested else-if statements It's better to write 'else if' than 'else { if }'.
2020-04-04 21:19:18 +02:00
obj.entities[i].yp -= 232;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldyp -= 232;
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
De-dupe screen transition / warping logic I noticed that the code for going to the adjacent room when offscreen and for warping instead if the room is warping was a bit copy-and-pasted. To clean up the code a bit, there's now 5 separate checks in gamelogic(): if (map.warpx) if (map.warpy) if (map.warpy && !map.warpx) if (!map.warpy) if (!map.warpx) I made sure to preserve the previous weird horizontal warping behavior that happens with vertical warping (thus the middle one), and to preserve the frame ordering just in case there's something dependent on the frame ordering. The frame ordering is that first it will warp you horizontally, if applicable, then it will warp you vertically, if applicable. Then if you have vertical warping only, that weird horizontal warp. Then it will screen transition you vertically, if applicable. Then it will screen transition you horizontally, if applicable. To explain the weird horizontal warp with the vertical warp: apparently if an entity is far offscreen enough, and if that entity is not the player, it will be warped horizontally during a vertical warp. The points at which it will warp is 30 pixels farther out than normal horizontal warping. I think someone ran into this before, but my memory is fuzzy. The best I can recall is that they were probably createentity()ing a high-speed horizontally-moving enemy in a vertically warping room, only to discover that said enemy kept warping horizontally.
2020-04-04 21:39:17 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (map.warpy && !map.warpx && !map.towermode)
De-dupe screen transition / warping logic I noticed that the code for going to the adjacent room when offscreen and for warping instead if the room is warping was a bit copy-and-pasted. To clean up the code a bit, there's now 5 separate checks in gamelogic(): if (map.warpx) if (map.warpy) if (map.warpy && !map.warpx) if (!map.warpy) if (!map.warpx) I made sure to preserve the previous weird horizontal warping behavior that happens with vertical warping (thus the middle one), and to preserve the frame ordering just in case there's something dependent on the frame ordering. The frame ordering is that first it will warp you horizontally, if applicable, then it will warp you vertically, if applicable. Then if you have vertical warping only, that weird horizontal warp. Then it will screen transition you vertically, if applicable. Then it will screen transition you horizontally, if applicable. To explain the weird horizontal warp with the vertical warp: apparently if an entity is far offscreen enough, and if that entity is not the player, it will be warped horizontally during a vertical warp. The points at which it will warp is 30 pixels farther out than normal horizontal warping. I think someone ran into this before, but my memory is fuzzy. The best I can recall is that they were probably createentity()ing a high-speed horizontally-moving enemy in a vertically warping room, only to discover that said enemy kept warping horizontally.
2020-04-04 21:39:17 +02: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
{
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
if(obj.entities[i].type<50 //Don't warp warp lines
&&obj.entities[i].rule!=0)
{
if (obj.entities[i].xp <= -30)
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
{
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
if (obj.entities[i].isplatform)
{
obj.moveblockto(obj.entities[i].xp, obj.entities[i].yp, obj.entities[i].xp + 350, obj.entities[i].yp, obj.entities[i].w, obj.entities[i].h);
}
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
obj.entities[i].xp += 350;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp += 350;
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
}
Condense some nested else-if statements It's better to write 'else if' than 'else { if }'.
2020-04-04 21:19:18 +02:00
else if (obj.entities[i].xp > 320)
Condense some nested if-statements in gamelogic() It's better to write if (cond1 && cond2) than it is to write if (cond1) { if (cond2) }.
2020-04-04 21:16:16 +02:00
{
Restore platform evaluation order to 2.2 This commit restores the evaluation order of moving platforms and conveyors to be what it was in 2.2. The evaluation order changed in 2.3 after the patchset to improve the handling of the `obj.entities` and `obj.blocks` vectors (#191). By evaluation order, I'm talking about the order in which platforms and conveyors will be evaluated (and thus will take priority) if Viridian stands on both a conveyor or platform at once, and they either have different speeds or are pointing in different directions. Nowhere in the main game is there a place where you can stand on two different conveyors/platforms at once, so this is solely within the territory of custom levels, which is my specialty. So what caused this evaluation order to change? Well, every moving platform and conveyor in the game is actually made up of two objects: an entity, and a block. The entity is the part that moves around, and the block is the part that actually has the collision. But if the entity is the part that moves around, and entities and blocks are in entirely separate vectors, how is the block part going to move along with it? Well, maybe you'd guess some sort of unique ID system, but spend some time digging around the code and you won't find any trace of any (there's no attribute on an entity to store such an ID, for starters). Instead, what the game does is actually remove all blocks that coincide with the exact top-left corner of the entity, and then create a new one. Destroying and creating blocks like this all the time is hugely wasteful, but hey, it worked. So why did the evaluation order change in 2.3? Well, to understand that, you'll need to understand 2.2's `active` system. Instead of having an object be real simply by virtue of it existing, 2.2 had this system where the object was only real if it had its `active` attribute set to true. In other words, you would be looking at a fake object that didn't actually exist if its `active` attribute was false. On the surface, this doesn't seem that bad. But this can lead to "holes" in a given vector of objects. A hole is simply an inactive object neighbored by active objects (or the inactive object could be the first one in the vector, but then have an active object immediately following it). If you have a vector of 3 objects, all of them active, then removing the second one will result in the vector containing an active object, followed by an inactive object, followed by an active one. However, since the switch to more properly use vectors instead of relying on this `active` system, there's no longer any way for holes to exist in a vector. Properly removing an object from a vector will just shift the rest of the objects down, so if we remove the second object after the vector fix, then this will simply move the third object into the slot of where the second object used to be. So, what happens if you destroy a block and then create a new one in the `active` system? Let's say that your `obj.blocks` looks like this, and here I'm denoting each block by writing out its coordinates: [30,60] [70,90] [80,100] and that you want to update the position of the second one, because the entity that that blocks belongs to has been updated. Okay, so, you delete that block, which then makes things look like this: [30,60] [-] [80,100] and then afterwards, you create a new block with the updated position, resulting in this: [30,60] [74,90] [80,100] Since `entityclass::createblock()` will find the first block slot that has a false `active` attribute, it puts the new object in the same slot as the old one. What has been essentially done here is that the slot of the block has basically been reserved for the new block with the new position. Here, the evaluation order of each block will stay the same. But then 2.3 comes along and changes things up. So we start with an `obj.blocks` like this again: [30,60] [70,90] [80,100] and we want to update the second block, like before. So we remove the second block, resulting in this: [30,60] [80,100] It should be obvious that unlike before, where the third block stayed in the third slot, the third block has now been moved to the second slot. But continuing on; we are now going to create the new block with its updated position, resulting in this: [30,60] [80,100] [70,90] At this point, we can see that the evaluation order of these blocks has been changed due to the fact that the third block has now been moved to the slot that was previously the slot of the second block. So what can we do about this? Well, we can basically emulate what VVVVVV did in 2.2, which is disable a block without actually removing it - except I'm not going to reintroduce an `active` attribute or anything. I'll disable the collision of all blocks at a certain position by setting their widths and heights to 0, and then re-enable them later by finding the first block at that same position, updating its position, and re-assigning its width and height again. The former is what `entityclass::nocollisionat()` does; the latter is what `entityclass::moveblockto()` does. The former mimicks turning off the `active` attribute of all blocks sharing a certain top-left corner; the latter mimicks creating a new block - and it will only do this for one block, because `entityclass::createblock()` in 2.2 only looked for the first block with a false `active` attribute. Now, some quirks relied on the previous behavior of destroying and creating blocks, but all of these quirks have been preserved with the way I implemented this fix. The first quirk is that platforms passing through 0,0 will destroy all spike hitboxes, script boxes, activity zones, and one-way hitboxes in the room. The hitboxes of moving platforms, disappearing platforms, 1x1 quicksand, and conveyors will not be affected. This is a consequence of the fact that the former group uses the `x` and `y` of their `rect`, while the latter group uses the `xp` and `yp` attributes. So the `xp` and `yp` of the former are both 0. Meaning, a platform passing through 0,0 destroys them all. Having these separate coordinates seems like an artifact from the Flash days. (And furthermore, there's an unused `x` and `y` attribute on all blocks, making for technically three separate sets of coordinates! This should probably be cleaned up, except for what I'm about to say...) But actually, if you merge both sets of coordinates into one, this lets moving platforms destroy script boxes and activity zones if it passes through the top-left corner of them, which is probably far worse than the destruction being localized to a specific coordinate that would never likely be reached normally. This quirk is preserved just fine without any special-casing, because instead of destroying all blocks at 0,0, they just get disabled, which does the same job. This quirk seems trivial to fix if I made it so that the position of a platform's block was updated instantaneously instead of having one step to disable it and another step to re-enable it, but I aim to preserve as much quirks as possible. The second quirk is that a moving platform passing through the top-left corner of a disappearing platform or 1x1 quicksand will destroy the block of that disappearing platform. This is because, again, when a moving platform updates, it destroys all blocks at its previous position, not just only one block. This is automatically preserved because this commit just disables the block of the disappearing platform instead of removing it. Just like the last one, this quirk seems extremely trivial to fix, and this time by simply making it so `entityclass::nocollisionat()` would have a `break` statement, i.e. only disabling the first block it finds instead of all blocks it finds, but I want to keep all quirks that are possible to keep. The last quirk is that, apparently, in order to prevent pushing the player vertically out of a moving platform if they get inside of one, the game destroys the block of the moving platform. If I had missed this edge case, then the block would've been destroyed, leaving the moving platform with no collision. But I caught it in my testing, so the block gets disabled instead of destroyed. Also, it seems obtuse for those who don't understand why a platform's block gets destroyed or disabled whenever the player collides with it in `entityclass::collisioncheck()`, so I've put up a comment documenting it as well. The different platform evaluation order desyncs my Nova TAS, but after applying this patchset and #504, my TAS syncs fine (save for the different walkingframe from starting immediately on the ground instead of in the air (#502), but that's minor and can be easily fixed). I've attached a test level to the pull request for this commit (#503) to demonstrate that this patchset not only fixes platform evaluation order, but preserves some bugs and quirks with the existing block system. The first room demonstrates the fixed platform evaluation order, by stepping on the conveyors that both point into each other. In 2.2, Viridian will move to the right of the background pillar, but in 2.3, Viridian will move to the left of the pillar. However, after applying this patch, Viridian will now move to the right of the pillar once again. The second room demonstrates that the platform-passing-through-0,0 trick still works (as explained above). The last room demonstrates that platforms passing through the top-left corners of disappearing platforms or 1x1 quicksand will remove the blocks of those entities, causing Viridian to immediately pass through them. This trick is still preserved after my patchset is applied.
2020-10-10 02:09:11 +02:00
if (obj.entities[i].isplatform)
{
obj.moveblockto(obj.entities[i].xp, obj.entities[i].yp, obj.entities[i].xp - 350, obj.entities[i].yp, obj.entities[i].w, obj.entities[i].h);
}
Condense some nested else-if statements It's better to write 'else if' than 'else { if }'.
2020-04-04 21:19:18 +02:00
obj.entities[i].xp -= 350;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp -= 350;
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
}
De-dupe screen transition / warping logic I noticed that the code for going to the adjacent room when offscreen and for warping instead if the room is warping was a bit copy-and-pasted. To clean up the code a bit, there's now 5 separate checks in gamelogic(): if (map.warpx) if (map.warpy) if (map.warpy && !map.warpx) if (!map.warpy) if (!map.warpx) I made sure to preserve the previous weird horizontal warping behavior that happens with vertical warping (thus the middle one), and to preserve the frame ordering just in case there's something dependent on the frame ordering. The frame ordering is that first it will warp you horizontally, if applicable, then it will warp you vertically, if applicable. Then if you have vertical warping only, that weird horizontal warp. Then it will screen transition you vertically, if applicable. Then it will screen transition you horizontally, if applicable. To explain the weird horizontal warp with the vertical warp: apparently if an entity is far offscreen enough, and if that entity is not the player, it will be warped horizontally during a vertical warp. The points at which it will warp is 30 pixels farther out than normal horizontal warping. I think someone ran into this before, but my memory is fuzzy. The best I can recall is that they were probably createentity()ing a high-speed horizontally-moving enemy in a vertically warping room, only to discover that said enemy kept warping horizontally.
2020-04-04 21:39:17 +02:00
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
bool screen_transition = false;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (!map.warpy && !map.towermode)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//Normal! Just change room
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) && game.door_down > -2 && obj.entities[player].yp >= 238)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[player].yp -= 240;
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
map.gotoroom(game.roomx, game.roomy + 1);
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
screen_transition = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(player, obj.entities) && game.door_up > -2 && obj.entities[player].yp < -2)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[player].yp += 240;
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
map.gotoroom(game.roomx, game.roomy - 1);
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
screen_transition = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
De-dupe screen transition / warping logic I noticed that the code for going to the adjacent room when offscreen and for warping instead if the room is warping was a bit copy-and-pasted. To clean up the code a bit, there's now 5 separate checks in gamelogic(): if (map.warpx) if (map.warpy) if (map.warpy && !map.warpx) if (!map.warpy) if (!map.warpx) I made sure to preserve the previous weird horizontal warping behavior that happens with vertical warping (thus the middle one), and to preserve the frame ordering just in case there's something dependent on the frame ordering. The frame ordering is that first it will warp you horizontally, if applicable, then it will warp you vertically, if applicable. Then if you have vertical warping only, that weird horizontal warp. Then it will screen transition you vertically, if applicable. Then it will screen transition you horizontally, if applicable. To explain the weird horizontal warp with the vertical warp: apparently if an entity is far offscreen enough, and if that entity is not the player, it will be warped horizontally during a vertical warp. The points at which it will warp is 30 pixels farther out than normal horizontal warping. I think someone ran into this before, but my memory is fuzzy. The best I can recall is that they were probably createentity()ing a high-speed horizontally-moving enemy in a vertically warping room, only to discover that said enemy kept warping horizontally.
2020-04-04 21:39:17 +02:00
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
if (!map.warpx && !map.towermode)
De-dupe screen transition / warping logic I noticed that the code for going to the adjacent room when offscreen and for warping instead if the room is warping was a bit copy-and-pasted. To clean up the code a bit, there's now 5 separate checks in gamelogic(): if (map.warpx) if (map.warpy) if (map.warpy && !map.warpx) if (!map.warpy) if (!map.warpx) I made sure to preserve the previous weird horizontal warping behavior that happens with vertical warping (thus the middle one), and to preserve the frame ordering just in case there's something dependent on the frame ordering. The frame ordering is that first it will warp you horizontally, if applicable, then it will warp you vertically, if applicable. Then if you have vertical warping only, that weird horizontal warp. Then it will screen transition you vertically, if applicable. Then it will screen transition you horizontally, if applicable. To explain the weird horizontal warp with the vertical warp: apparently if an entity is far offscreen enough, and if that entity is not the player, it will be warped horizontally during a vertical warp. The points at which it will warp is 30 pixels farther out than normal horizontal warping. I think someone ran into this before, but my memory is fuzzy. The best I can recall is that they were probably createentity()ing a high-speed horizontally-moving enemy in a vertically warping room, only to discover that said enemy kept warping horizontally.
2020-04-04 21:39:17 +02:00
{
//Normal! Just change room
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) && game.door_left > -2 && obj.entities[player].xp < -14)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[player].xp += 320;
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
map.gotoroom(game.roomx - 1, game.roomy);
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
screen_transition = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(player, obj.entities) && game.door_right > -2 && obj.entities[player].xp >= 308)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
obj.entities[player].xp -= 320;
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
map.gotoroom(game.roomx + 1, game.roomy);
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
screen_transition = true;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
//Right so! Screenwraping for tower:
Add towermode checks to minitowermode screen transitions Apparently, the game just leaves minitowermode on, which can cause issues if you're in a horizontal warping room (and not any other room type, due to how frame ordering works). This would manifest itself as a wrong warp to (20,20) because the game is trying to apply the hardcoded minitower screen transitions when it shouldn't be.
2020-05-05 20:26:26 +02:00
if (map.towermode && map.minitowermode)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
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 (graphics.towerbg.scrolldir == 1)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
//This is minitower 1!
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) && game.door_left > -2 && obj.entities[player].xp < -14)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
obj.entities[player].xp += 320;
map.gotoroom(48, 52);
}
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) && game.door_right > -2 && obj.entities[player].xp >= 308)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
obj.entities[player].xp -= 320;
obj.entities[player].yp -= (71*8);
map.gotoroom(game.roomx + 1, game.roomy+1);
}
}
else
{
//This is minitower 2!
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) && game.door_left > -2 && obj.entities[player].xp < -14)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
if (obj.entities[player].yp > 300)
{
obj.entities[player].xp += 320;
obj.entities[player].yp -= (71 * 8);
map.gotoroom(50, 54);
}
else
{
obj.entities[player].xp += 320;
map.gotoroom(50, 53);
}
}
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) && game.door_right > -2 && obj.entities[player].xp >= 308)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
obj.entities[player].xp -= 320;
map.gotoroom(52, 53);
}
}
}
else if (map.towermode)
{
//Always wrap except for the very top and very bottom of the tower
if(map.ypos>=500 && map.ypos <=5000)
{
for (size_t i = 0; i < obj.entities.size(); i++)
{
if (obj.entities[i].xp <= -10)
{
obj.entities[i].xp += 320;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp += 320;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
}
Simplify "else if" indentation for right-side tower screen wrapping No need to make an entire else-block and indent it when you can just do "else if" instead.
2020-04-29 01:45:53 +02:00
else if (obj.entities[i].xp > 310)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
Simplify "else if" indentation for right-side tower screen wrapping No need to make an entire else-block and indent it when you can just do "else if" instead.
2020-04-29 01:45:53 +02:00
obj.entities[i].xp -= 320;
Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp I was investigating a desync in my Nova TAS, and it turns out that the gravity line collision functions check for the `oldxp` and `oldyp` of the player, i.e. their position on the previous frame, along with their position on the current frame. So, if the player either collided with the gravity line last frame or this frame, then the player collided with the gravity line this frame. Except, that's not actually true. It turns out that `oldxp` and `oldyp` don't necessarily always correspond to the `xp` and `yp` of the player on the previous frame. It turns out that your `oldyp` will be updated if you stand on a vertically moving platform, before the gravity line collision function gets ran. So, if you were colliding with a gravity line on the previous frame, but you got moved out of there by a vertically moving platform, then you just don't collide with the gravity line at all. However, this behavior changed in 2.3 after my over-30-FPS patch got merged (#220). That patch took advantage of the existing `oldxp` and `oldyp` entity attributes, and uses them to interpolate their positions during rendering to make everything look real smooth. Previously, `oldxp` and `oldyp` would both be updated in `entityclass::updateentitylogic()`. However, I moved it in that patch to update right before `gameinput()` in `main.cpp`. As a result, `oldyp` no longer gets updated whenever the player stands on a vertically moving platform. This ends up desyncing my TAS. As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the function responsible for moving the player whenever they stand on a vertically moving platform) makes it so that my TAS syncs, but the visuals are glitchy when standing on a vertically moving platform. And as much as I'd like to get rid of gravity lines checking for whether you've collided with them on the previous frame, doing that desyncs my TAS, too. In the end, it seems like I should just leave `oldxp` and `oldyp` alone, and switch to using dedicated variables that are never used in the physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS patch added, with `lerpoldxp` and `lerpoldyp` instead. After doing this, and applying #503 as well, my Nova TAS syncs after some minor but acceptable fixes with Viridian's walkingframe.
2020-10-10 05:58:58 +02:00
obj.entities[i].lerpoldxp -= 320;
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
}
}
}
else
{
//Do not wrap! Instead, go to the correct room
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) && game.door_left > -2 && obj.entities[player].xp < -14)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
obj.entities[player].xp += 320;
obj.entities[player].yp -= (671 * 8);
map.gotoroom(108, 109);
}
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) && game.door_right > -2 && obj.entities[player].xp >= 308)
Merge towerlogic() into gamelogic() This doesn't change anything functionality-wise, but it does remove a lot of duplicate code, which makes it easier to work on.
2020-04-25 06:19:41 +02:00
{
obj.entities[player].xp -= 320;
map.gotoroom(110, 104);
}
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//Warp tokens
if (map.custommode){
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
if (game.teleport)
{
int edi=obj.entities[game.edteleportent].behave;
int edj=obj.entities[game.edteleportent].para;
int edi2, edj2;
edi2 = (edi-(edi%40))/40;
edj2 = (edj-(edj%30))/30;
map.warpto(100+edi2, 100+edj2, obj.getplayer(), edi%40, (edj%30)+2);
game.teleport = false;
if (game.teleport == false)
{
game.flashlight = 6;
game.screenshake = 25;
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}else{
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
if (game.teleport)
{
if (game.roomx == 117 && game.roomy == 102)
{
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 = 225;
}
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
map.gotoroom(119, 100);
game.teleport = false;
}
else if (game.roomx == 119 && game.roomy == 100)
{
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 = 225;
}
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
map.gotoroom(119, 103);
game.teleport = false;
}
else if (game.roomx == 119 && game.roomy == 103)
{
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = 0;
}
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
map.gotoroom(116, 103);
game.teleport = false;
}
else if (game.roomx == 116 && game.roomy == 103)
{
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 = 225;
}
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
map.gotoroom(116, 100);
game.teleport = false;
}
else if (game.roomx == 116 && game.roomy == 100)
{
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(i, obj.entities))
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
{
obj.entities[i].xp = 0;
}
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
map.gotoroom(114, 102);
game.teleport = false;
}
else if (game.roomx == 114 && game.roomy == 102)
{
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 = 225;
}
Clean up some indentation in gamelogic() This is just a miscellaneous indentation cleanup to fix some places where it is indented with 2 spaces instead of 4.
2020-04-04 21:13:24 +02:00
map.gotoroom(113, 100);
game.teleport = false;
}
else if (game.roomx == 116 && game.roomy == 104)
{
//pre warp zone here
map.warpto(107, 101, obj.getplayer(), 14, 16);
}
else if (game.roomx == 107 && game.roomy == 101)
{
map.warpto(105, 119, obj.getplayer(), 5, 26);
}
else if (game.roomx == 105 && game.roomy == 118)
{
map.warpto(101, 111, obj.getplayer(), 34, 6);
}
else if (game.roomx == 101 && game.roomy == 111)
{
//There are lots of warp tokens in this room, so we have to distinguish!
switch(game.teleportxpos)
{
case 1:
map.warpto(108, 108, obj.getplayer(), 4, 27);
break;
case 2:
map.warpto(101, 111, obj.getplayer(), 12, 27);
break;
case 3:
map.warpto(119, 111, obj.getplayer(), 31, 7);
break;
case 4:
map.warpto(114, 117, obj.getplayer(), 19, 16);
break;
}
}
else if (game.roomx == 108 && game.roomy == 106)
{
map.warpto(119, 111, obj.getplayer(), 4, 27);
}
else if (game.roomx == 100 && game.roomy == 111)
{
map.warpto(101, 111, obj.getplayer(), 24, 6);
}
else if (game.roomx == 119 && game.roomy == 107)
{
//Secret lab, to super gravitron
map.warpto(119, 108, obj.getplayer(), 19, 10);
}
if (game.teleport == false)
{
game.flashlight = 6;
game.screenshake = 25;
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
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
if (screen_transition)
{
map.twoframedelayfix();
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Move finalstretch animation code to gamelogic() Otherwise, the tile animations will go too fast. However, the overall color cycling hasn't been going fast, since it was never in gamerender() in the first place.
2020-04-30 21:32:53 +02:00
//Update colour cycling for final level
if (map.finalmode && map.final_colormode)
{
map.final_aniframedelay--;
if(map.final_aniframedelay==0)
{
graphics.foregrounddrawn=false;
}
if (map.final_aniframedelay <= 0) {
map.final_aniframedelay = 2;
map.final_aniframe++;
if (map.final_aniframe >= 4)
map.final_aniframe = 0;
}
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
if (game.roomchange)
{
//We've changed room? Let's bring our companion along!
game.roomchange = false;
Guard all cases obj.getplayer() is used unchecked obj.getplayer() can return -1, which can cause out-of-bounds indexing of obj.entities, which is really bad. This was by far the most changes, as obj.getplayer() is the most used entity-getting function that returns -1, as well as the most-used function whose sentinel value goes unchecked. To deal with the usage of obj.getplayer() in mapclass::warpto(), I just added general bounds checks inside that function instead of changing all the callers.
2020-06-13 05:36:08 +02:00
int i = obj.getplayer();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (game.companion > 0 && INBOUNDS_VEC(i, obj.entities))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
//ok, we'll presume our companion has been destroyed in the room change. So:
switch(game.companion)
{
case 6:
Reduce scope of 'j' in screen transition companion logic Reducing the scope of the variable makes analysis easier - for example, we can now see it is always initialized before being used.
2020-09-08 23:59:23 +02:00
{
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(obj.entities[i].xp, 121.0f, 15.0f,1); //Y=121, the floor in that particular place!
Reduce scope of 'j' in screen transition companion logic Reducing the scope of the variable makes analysis easier - for example, we can now see it is always initialized before being used.
2020-09-08 23:59:23 +02:00
int j = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[j].vx = obj.entities[i].vx;
obj.entities[j].dir = obj.entities[i].dir;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
Reduce scope of 'j' in screen transition companion logic Reducing the scope of the variable makes analysis easier - for example, we can now see it is always initialized before being used.
2020-09-08 23:59:23 +02:00
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
case 7:
if (game.roomy <= 105) //don't jump after him!
{
if (game.roomx == 110)
{
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(320, 86, 16, 1); //Y=86, the ROOF in that particular place!
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
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(obj.entities[i].xp, 86.0f, 16.0f, 1); //Y=86, the ROOF in that particular place!
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Reduce scope of 'j' in screen transition companion logic Reducing the scope of the variable makes analysis easier - for example, we can now see it is always initialized before being used.
2020-09-08 23:59:23 +02:00
int j = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[j].vx = obj.entities[i].vx;
obj.entities[j].dir = obj.entities[i].dir;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 8:
if (game.roomy >= 104) //don't jump after him!
{
if (game.roomx == 102)
{
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(310, 177, 17, 1);
Reduce scope of 'j' in screen transition companion logic Reducing the scope of the variable makes analysis easier - for example, we can now see it is always initialized before being used.
2020-09-08 23:59:23 +02:00
int j = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[j].vx = obj.entities[i].vx;
obj.entities[j].dir = obj.entities[i].dir;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
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(obj.entities[i].xp, 177.0f, 17.0f, 1);
Reduce scope of 'j' in screen transition companion logic Reducing the scope of the variable makes analysis easier - for example, we can now see it is always initialized before being used.
2020-09-08 23:59:23 +02:00
int j = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[j].vx = obj.entities[i].vx;
obj.entities[j].dir = obj.entities[i].dir;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
break;
case 9:
if (!map.towermode) //don't go back into the tower!
{
if (game.roomx == 110 && obj.entities[i].xp<20)
{
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(100, 185, 18, 15, 0, 1);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
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(obj.entities[i].xp, 185.0f, 18.0f, 15, 0, 1);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Reduce scope of 'j' in screen transition companion logic Reducing the scope of the variable makes analysis easier - for example, we can now see it is always initialized before being used.
2020-09-08 23:59:23 +02:00
int j = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[j].vx = obj.entities[i].vx;
obj.entities[j].dir = obj.entities[i].dir;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 10:
//intermission 2, choose colour based on lastsaved
if (game.roomy == 51)
{
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[59])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(225.0f, 169.0f, 18, graphics.crewcolour(game.lastsaved), 0, 10);
Reduce scope of 'j' in screen transition companion logic Reducing the scope of the variable makes analysis easier - for example, we can now see it is always initialized before being used.
2020-09-08 23:59:23 +02:00
int j = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[j].vx = obj.entities[i].vx;
obj.entities[j].dir = obj.entities[i].dir;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
else if (game.roomy >= 52)
{
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[59])
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(160.0f, 177.0f, 18, graphics.crewcolour(game.lastsaved), 0, 18, 1);
Reduce scope of 'j' in screen transition companion logic Reducing the scope of the variable makes analysis easier - for example, we can now see it is always initialized before being used.
2020-09-08 23:59:23 +02:00
int j = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[j].vx = obj.entities[i].vx;
obj.entities[j].dir = obj.entities[i].dir;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
else
{
Declare obj.flags a vector of bools instead of ints It's treated like a bool anyway, so might as well make it one. This also necessitates updating every single instance where it or an element inside it is used, too.
2020-04-09 08:34:26 +02:00
obj.flags[59] = true;
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(obj.entities[i].xp, -20.0f, 18.0f, graphics.crewcolour(game.lastsaved), 0, 10, 0);
Reduce scope of 'j' in screen transition companion logic Reducing the scope of the variable makes analysis easier - for example, we can now see it is always initialized before being used.
2020-09-08 23:59:23 +02:00
int j = obj.getcompanion();
Use explicit INBOUNDS_VEC() instead of checking sentinel -1 It's better to do INBOUNDS_VEC(i, obj.entities) instead of 'i > -1'. 'i > -1' is used in cases like obj.getplayer(), which COULD return a sentinel value of -1 and so correct code will have to check that value. However, I am now of the opinion that INBOUNDS_VEC() should be used and isn't unnecessary. Consider the case of the face() script command: it's not enough to check i > -1, you should read the routine carefully. Because if you look closely, you'll see that it's not guaranteed that 'i' will be initialized at all in that command. Indeed, if you call face() with invalid arguments, it won't be. And so, 'i' could be something like 215, and that would index out-of-bounds, and that wouldn't be good. Therefore, it's better to have the full bounds check instead of checking only one bounds. Many commands are like this, after some searching I can also name position(), changemood(), changetile(), changegravity(), etc. It also makes the code more explicit. Now you don't have to wonder what -1 means or why it's being checked, you can just read the 'INBOUNDS' and go "oh, that checks if it's actually inbounds or not".
2020-09-09 13:15:14 +02:00
if (INBOUNDS_VEC(j, obj.entities))
Guard all cases obj.getcompanion() is used unchecked And this the function with the least amount of cases where its sentinel value is used unchecked. Thankfully. obj.getplayer() was a bit of a slug to get through.
2020-06-13 05:43:19 +02:00
{
obj.entities[j].vx = obj.entities[i].vx;
obj.entities[j].dir = obj.entities[i].dir;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
}
break;
case 11:
//Intermission 1: We're using the SuperCrewMate instead!
if(game.roomx-41==game.scmprogress)
{
switch(game.scmprogress)
{
case 0:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(76, 161, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 1:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 169, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 2:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 177, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 3:
if (game.scmmoveme)
{
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(obj.entities[obj.getplayer()].xp, 185, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.scmmoveme = false;
}
else
{
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 177, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
break;
case 4:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 185, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 5:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 185, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 6:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 185, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 7:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 41, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 8:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 169, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 9:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 169, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 10:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 129, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 11:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 129, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 12:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 65, 24, graphics.crewcolour(game.lastsaved), 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
case 13:
Remove global args from Logic.cpp This commit removes the passing around of global args in the logic functions. Additionally, all 'dwgfx' has been replaced with 'graphics' in Logic.cpp.
2020-04-01 23:48:11 +02:00
obj.createentity(10, 177, 24, graphics.crewcolour(game.lastsaved));
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
break;
}
}
if (game.scmmoveme)
{
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
int scm = obj.getscm();
int player = obj.getplayer();
if (INBOUNDS_VEC(scm, obj.entities) && INBOUNDS_VEC(player, obj.entities))
{
obj.entities[scm].xp = obj.entities[player].xp;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
game.scmmoveme = false;
}
break;
}
}
}
game.activeactivity = obj.checkactivity();
Interpolate "- Press ENTER to Teleport -" prompt This is only really noticeable in slowmode, but if you're playing in slowmode it'll be pretty smooth.
2020-04-30 02:04:25 +02:00
game.oldreadytotele = game.readytotele;
Move tele/activity/trophytext conds to collision detection This moves the teleporter, activity prompt, and trophy text "don't draw" conditionals to the part where the game checks collision with them, instead of whenever the game draws them. This makes it so that the game smoothly does the fade-in/fade-out animation instead of suddenly stopping rendering them whenever their "don't draw" conditions apply. Now, the "Press ENTER to activate terminal" prompt will no longer suddenly disappear whenever you activate one, and the "- Press ENTER to Teleport -" prompt will smoothly fade back in after teleporting, instead of suddenly popping in on screen.
2020-08-03 06:02:27 +02:00
if (game.activetele && !game.advancetext && game.hascontrol && !script.running && !game.intimetrial)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
int i = obj.getplayer();
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
SDL_Rect temprect = SDL_Rect();
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
{
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
temprect.x = obj.entities[i].xp + obj.entities[i].cx;
temprect.y = obj.entities[i].yp + obj.entities[i].cy;
temprect.w = obj.entities[i].w;
temprect.h = obj.entities[i].h;
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
}
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
if (help.intersects(game.teleblock, temprect))
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
game.readytotele += 25;
if (game.readytotele >= 255) game.readytotele = 255;
}
else
{
game.readytotele -= 50;
if (game.readytotele < 0) game.readytotele = 0;
}
}
else
{
if (game.readytotele > 0)
{
game.readytotele -= 50;
if (game.readytotele < 0) game.readytotele = 0;
}
}
if (game.teleport_to_new_area)
Remove global args from scriptclass This commit removes all global args from the parameters of each function on the scriptclass object, and updates all places they are called accordingly. It also changes all instances of 'dwgfx' to 'graphics' in Script.cpp. Interestingly enough, it looks like editor.h depended on Script.h's class define of the musicclass. I've temporarily placed the class define in editor.h, but by the end of this patchset it'll be gone.
2020-03-31 21:38:52 +02:00
script.teleport();
Move returning to editor to end of frame This fixes horizontal and vertical warp backgrounds not resetting, and also a bunch of other 1-frame glitches, most noticeably cutscene bars and fadeouts. This adds a new variable shouldreturntoeditor to Game to signal whether or not it should return to editor at the end of the frame.
2020-05-09 21:52:58 +02:00
#if !defined(NO_CUSTOM_LEVELS)
if (game.shouldreturntoeditor)
{
game.returntoeditor();
}
#endif
Update activity prompt fade in fixed-timestep gamelogic() Otherwise it goes by too quickly.
2020-04-29 03:15:26 +02:00
Interpolate activity zone prompt fading in and out To make it real smooth, just in case it was noticeable that it only updated at 1000/34 FPS before (well, except in slowmode, it's really noticeable THERE). Also this removes the re-typing out of (game.act_fade/10.0f) for every single R, G, and B in gamerender().
2020-04-29 06:58:19 +02:00
game.prev_act_fade = game.act_fade;
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(game.activeactivity, obj.blocks) && game.hascontrol && !script.running)
Update activity prompt fade in fixed-timestep gamelogic() Otherwise it goes by too quickly.
2020-04-29 03:15:26 +02:00
{
if (game.act_fade < 5)
{
game.act_fade = 5;
}
if (game.act_fade < 10)
{
game.act_fade++;
}
}
else if (game.act_fade > 5)
{
game.act_fade--;
}
Update trophy text timer in fixed-timestep gamelogic() Otherwise it, too, goes by too quickly.
2020-04-29 03:15:56 +02:00
if (obj.trophytext > 0)
{
obj.trophytext--;
}
Update text boxes in the inner fixed-timestep loop So they don't go really quickly.
2020-04-29 03:38:43 +02:00
graphics.updatetextboxes();
Update left-moving star BG in fixed timestep loop Otherwise they will move too fast.
2020-04-29 04:28:16 +02:00
if (!game.colourblindmode)
{
Move tower background update code to logic functions Otherwise it'll go really really quickly, which is not good.
2020-04-30 00:25:01 +02:00
if (map.towermode)
{
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.updatetowerbackground(graphics.towerbg);
Move tower background update code to logic functions Otherwise it'll go really really quickly, which is not good.
2020-04-30 00:25:01 +02:00
}
else
{
graphics.updatebackground(map.background);
}
Update left-moving star BG in fixed timestep loop Otherwise they will move too fast.
2020-04-29 04:28:16 +02:00
}
Move gravity line color updating to gamelogic() So it doesn't keep updating really quickly.
2020-04-29 06:17:16 +02:00
if (!game.blackout)
{
//Update line colours!
if (graphics.linedelay <= 0)
{
graphics.linestate++;
if (graphics.linestate >= 10) graphics.linestate = 0;
graphics.linedelay = 2;
}
else
{
graphics.linedelay--;
}
}
Fix, for in-GAMEMODE sprites, their colors updating too fast Okay, so the problem here is that Graphics::setcol() is called right before a sprite is drawn in a render function, but render functions are done in deltatime, meaning that the color of a sprite keeps being recalculated every time. This only affects sprites that use fRandom() (the other thing that can dynamically determine a color is help.glow, but that's only updated in the fixed-timestep loop), but is especially noticeable for sprites that flash wildly, like the teleporter, trinket, and elephant. To fix this, we need to make the color be recalculated only in the fixed-timestep loop. However, this means that we MUST store the color of the sprite SOMEWHERE for the delta-timesteps to render it, otherwise the color calculation will just be lost or something. So each entity now has a new attribute, `realcol`, which is the actual raw color used to render the sprite in render functions. This is not to be confused with their `colour` attribute, which is more akin to a color "ID" of sorts, but which isn't an actual color. At the end of gamelogic(), as well as when an entity is first created, the `colour` is given to Graphics::setcol() and then `realcol` gets set to the actual color. Then when it comes time to render the entity, `realcol` gets used instead. Gravitron squares are a somewhat tricky case where there's technically TWO colors for it - one is the actual sprite itself and the other is the indicator. However, usually the indicator and the square aren't both onscreen at the same time, so we can simply switch the realcol between the two as needed. However, we can't use this system for the sprite colors used on the title and map screen, so we'll have to do something else for those.
2020-05-01 02:34:37 +02:00
graphics.trinketcolset = false;
for (int i = obj.entities.size() - 1; i >= 0; i--)
{
if (obj.entities[i].invis)
{
continue;
}
obj.entities[i].updatecolour();
}
Move glitch roomname updating to logic functions Otherwise they go by so fast that it's basically impossible to see them.
2020-05-02 19:31:48 +02:00
if (map.finalmode)
{
map.glitchname = map.getglitchname(game.roomx, game.roomy);
}
Move "return to editor" alpha timer update to logic functions Otherwise it'll go by too quickly. Also something subtle here - I didn't make it conditional on game.advancetext, so now it'll still decrement even if you have advancetext up.
2020-05-02 19:45:35 +02:00
#if !defined(NO_CUSTOM_LEVELS)
Smoothly interpolate "[Press ENTER to return to editor]" fadeout Now it'll be real smooth at 60 FPS. Or above. Or whichever one you want above 30.
2020-05-02 19:49:41 +02:00
ed.oldreturneditoralpha = ed.returneditoralpha;
Move "return to editor" alpha timer update to logic functions Otherwise it'll go by too quickly. Also something subtle here - I didn't make it conditional on game.advancetext, so now it'll still decrement even if you have advancetext up.
2020-05-02 19:45:35 +02:00
if (map.custommode && !map.custommodeforreal && ed.returneditoralpha > 0)
{
ed.returneditoralpha -= 15;
}
Fix editor ghosts being added multiple times per frame This just results in a messy splotchy effect. Instead, move the ghost adding outside of the render function.
2020-06-13 02:20:37 +02:00
// Editor ghosts!
if (game.ghostsenabled)
{
if (map.custommode && !map.custommodeforreal)
{
if (game.gametimer % 3 == 0)
{
int i = obj.getplayer();
GhostInfo ghost;
ghost.rx = game.roomx-100;
ghost.ry = game.roomy-100;
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))
Fix editor ghosts being added multiple times per frame This just results in a messy splotchy effect. Instead, move the ghost adding outside of the render function.
2020-06-13 02:20:37 +02:00
{
ghost.x = obj.entities[i].xp;
ghost.y = obj.entities[i].yp;
ghost.col = obj.entities[i].colour;
Fix editor ghost colors updating too fast Like actual entities, editor ghost colors were updating every render frame instead of logic frame. So just like actual entities, I added a realcol attribute to them that editorrender() uses instead, and added code to update said realcol attribute in editorlogic(). That way the colors don't go by too quickly (especially the death color).
2020-06-13 02:34:19 +02:00
ghost.realcol = obj.entities[i].realcol;
Fix editor ghosts being added multiple times per frame This just results in a messy splotchy effect. Instead, move the ghost adding outside of the render function.
2020-06-13 02:20:37 +02:00
ghost.frame = obj.entities[i].drawframe;
}
ed.ghosts.push_back(ghost);
}
if (ed.ghosts.size() > 100)
{
ed.ghosts.erase(ed.ghosts.begin());
}
}
}
Move "return to editor" alpha timer update to logic functions Otherwise it'll go by too quickly. Also something subtle here - I didn't make it conditional on game.advancetext, so now it'll still decrement even if you have advancetext up.
2020-05-02 19:45:35 +02:00
#endif
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Reference in a new issue Copy permalink