mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-12-23 01:59:43 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/RenderFixed.cpp

287 lines
6.9 KiB
C++
Raw Normal View History

Rename editor.h to CustomLevels.h This accompanies the editor.cpp -> CustomLevels.cpp change; I'll be splitting out the editor functions in the next commit. The name of the include guard has been changed as well, but not anything else.
2021-02-20 08:19:09 +01:00
#include "CustomLevels.h"
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
#include "Game.h"
#include "Graphics.h"
Move all editor-specific attributes to a new editorclass This is a pretty hefty commit! But essentially, I made a new editorclass object, and moved all functions and variables that only get used in the in-game level editor to that class. This cleanly demarcates which things are in the editor and which things are just general custom level stuff. Then I fixed up all the callers. I also fixed up some NO_CUSTOM_LEVELS and NO_EDITOR ifdefs, too, in several places.
2021-02-21 00:40:11 +01:00
#include "Editor.h"
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
#include "Entity.h"
#include "Enums.h"
#include "Map.h"
#include "Script.h"
#include "UtilityClass.h"
Remove now-unneeded deltaframe fix when going to in-game settings Previously, before the game loop order got fixed, going to the in-game settings would switch over to the new render function too early, causing a deltaframe glitch that had to be fixed. But now, the render function only gets switched when the current gamestate's function list gets finished executing, so the game won't suddenly switch to titlerender() in the middle of the ACTION press to the in-game settings screen. As a consequence, titleupdatetextcol() no longer needs to be exported to Input.cpp.
2020-11-10 09:27:42 +01:00
static inline void titleupdatetextcol(void)
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
{
Move mapclass r/g/b variables off onto TowerBG This fixes a bug where if you entered a tower before watching the credits sequence, the credits sequence would have mismatched text and background colors. This bug happened because entering a tower modified the r/g/b attributes of mapclass, and updated graphics.towerbg, without updating graphics.titlebg too. Then gamecompleterender() uses the r/g/b attributes of mapclass. The solution is to put the r/g/b attributes on TowerBG instead. That way, entering a tower will only modify the r/g/b attributes used to render towers, and won't affect the r/g/b attributes used to render the credits sequence. Additionally, I also de-duplicated the case-switch that updated the r/g/b attributes based off of the current colstate, because it got copy-pasted twice, leading to three instances of one piece of code.
2021-01-08 02:37:38 +01:00
graphics.col_tr = graphics.titlebg.r - (help.glow / 4) - int(fRandom() * 4);
graphics.col_tg = graphics.titlebg.g - (help.glow / 4) - int(fRandom() * 4);
graphics.col_tb = graphics.titlebg.b - (help.glow / 4) - int(fRandom() * 4);
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
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;
}
Show skip prompt during credits and ending picture This adds a "- Press {button} to skip -" prompt to both the credits and ending picture sequences. It was always possible to skip them by pressing Enter, but not many people knew this. In fact, even I didn't know this until I saw Elomavi do it a year or so ago. So it's not really intuitive that this is possible. The prompt only shows up if you've completed the game before, and disappears after two seconds similar to the "[Press {button} to return to editor]" text. Unfortunately, given how the game works, game completion is detected based on if you have unlocked Flip Mode or not. At this point, the unlock for the game being completed (unlock 5) will already be set to true no matter what during the Plenary fanfare, but the Flip Mode unlock (unlock 18) won't be until the player hits "play" on the main menu. As a special case, the prompt will always show up in M&P (because Flip Mode is always unlocked in M&P).
2023-05-22 21:18:40 +02:00
static inline void tick_skip_message_timer(void)
{
const bool tick = graphics.fademode == FADE_NONE;
if (!tick)
{
return;
}
game.old_skip_message_timer = game.skip_message_timer;
if (game.skip_message_timer > 0)
{
game.skip_message_timer -= 15;
}
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void gamerenderfixed(void)
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
{
if (!game.blackout && !game.completestop)
{
for (size_t i = 0; i < obj.entities.size(); i++)
{
if (obj.entitycollidefloor(i))
{
Move logical onground/onroof updates to start of gamelogic This reintroduces 2-frame edge-flipping after the 1-frame input delay got removed. This is because along with processing input and moving Viridian, logical onground/onroof assignments need to processed in the same between-render sequence as well - otherwise Viridian only gets 1 frame of edge-flipping due to frame ordering.
2021-03-18 21:20:56 +01:00
obj.entities[i].visualonground = 2;
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
}
else
{
Move logical onground/onroof updates to start of gamelogic This reintroduces 2-frame edge-flipping after the 1-frame input delay got removed. This is because along with processing input and moving Viridian, logical onground/onroof assignments need to processed in the same between-render sequence as well - otherwise Viridian only gets 1 frame of edge-flipping due to frame ordering.
2021-03-18 21:20:56 +01:00
--obj.entities[i].visualonground;
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
}
if (obj.entitycollideroof(i))
{
Move logical onground/onroof updates to start of gamelogic This reintroduces 2-frame edge-flipping after the 1-frame input delay got removed. This is because along with processing input and moving Viridian, logical onground/onroof assignments need to processed in the same between-render sequence as well - otherwise Viridian only gets 1 frame of edge-flipping due to frame ordering.
2021-03-18 21:20:56 +01:00
obj.entities[i].visualonroof = 2;
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
}
else
{
Move logical onground/onroof updates to start of gamelogic This reintroduces 2-frame edge-flipping after the 1-frame input delay got removed. This is because along with processing input and moving Viridian, logical onground/onroof assignments need to processed in the same between-render sequence as well - otherwise Viridian only gets 1 frame of edge-flipping due to frame ordering.
2021-03-18 21:20:56 +01:00
--obj.entities[i].visualonroof;
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
}
//Animate the entities
obj.animateentities(i);
}
}
game.prev_act_fade = game.act_fade;
if (INBOUNDS_VEC(game.activeactivity, obj.blocks) && game.hascontrol && !script.running)
{
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--;
}
if (obj.trophytext > 0)
{
obj.trophytext--;
}
Inline cutscene bars timer for gamemodes that used it in 2.2 As part of my work in #535, I've noticed that 2.3 currently with 2.2 loop order doesn't have interpolated cutscene bars. This is because cutscene bars in 2.3 get updated at the start of the frame, which interpolates them correctly until the render functions are put in their proper place. There is, however, a somewhat bigger issue, outside the scope of #535, where cutscene bars always get updated regardless of which gamemode you are in. Previously in 2.2 and previous, cutscene bars only got updated in GAMEMODE and TELEPORTERMODE; sometime during 2.3, the cutscene bars timer got pulled out of all the individual game modes and moved to the very start of the loop. (I was probably the one who did this change; I've been caught in a trap of my own devising.) Thus, going to MAPMODE during the cutscene bars animation doesn't keep their position paused like it would in 2.2. This is also categorically a more-than-visual change, since the untilbars() script command depends on the cutscene bars timer. I see no reason for the cutscene bars to behave differently in this way than 2.2; #535 would also end up doing the same fix more-or-less anyway. Since TELEPORTERMODE currently uses the same renderfixed function as MAPMODE, I've had to add a teleporterrenderfixed() that just calls maprenderfixed(), but also does the cutscene bars timer.
2021-03-17 08:28:47 +01:00
graphics.cutscenebarstimer();
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
graphics.updatetextboxes();
if (!game.colourblindmode)
{
if (map.towermode)
{
graphics.updatetowerbackground(graphics.towerbg);
}
else
{
graphics.updatebackground(map.background);
}
}
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--;
}
}
graphics.trinketcolset = false;
for (int i = obj.entities.size() - 1; i >= 0; i--)
{
if (obj.entities[i].invis)
{
continue;
}
obj.entities[i].updatecolour();
}
Animated roomnames, setroomname command This commit adds a better system for animated roomnames. The old system, like many other systems, were very hardcoded, and can be described as mostly else-if chains, with some fun string comparisons. The new system uses lists of text for transformations and glitchy names, making it much easier to add new cases if needeed. This commit implements the system but does not replace the old system, where that is done in the next commit. The settings for special roomnames can be read from level XML, and `setroomname()` can be used from commands to set a new, static name.
2022-12-12 00:05:20 +01:00
map.updateroomnames();
Clean up scripts in the editor Scripts used a weird "hook" system, where script names were extracted into their own list. This was completely unneeded, so it has been replaced with using the script.customscripts vector directly. The script editor has been cleaned up, so the cursor's Y position is relative to the entire script, rather than what's just displaying on the screen currently. This simplifies a lot of code, and I don't know why it was done the other way in the first place. The script selector and script editor cursors have been sped up, since both lists can be massive, and waiting 6 frames per line is extremely slow and boring. This is still slow and boring, but we don't have proper input repetition yet.
2023-03-09 18:10:58 +01:00
ed.old_return_message_timer = ed.return_message_timer;
if (map.custommode && !map.custommodeforreal && ed.return_message_timer > 0)
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
{
Clean up scripts in the editor Scripts used a weird "hook" system, where script names were extracted into their own list. This was completely unneeded, so it has been replaced with using the script.customscripts vector directly. The script editor has been cleaned up, so the cursor's Y position is relative to the entire script, rather than what's just displaying on the screen currently. This simplifies a lot of code, and I don't know why it was done the other way in the first place. The script selector and script editor cursors have been sped up, since both lists can be massive, and waiting 6 frames per line is extremely slow and boring. This is still slow and boring, but we don't have proper input repetition yet.
2023-03-09 18:10:58 +01:00
ed.return_message_timer -= 15;
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
}
Indicate modes when loading in to gameplay If you load in to gameplay with invincibility mode, glitchrunner mode, Flip Mode, or slowdown enabled, then there will be text displayed on screen for a few seconds that says so. This is to serve as a useful reminder. A common pitfall with using invincibility is forgetting to turn it off when you don't want it anymore. What usually happens is that players forget that they have it on until they encounter a hazard. Now, they can realize it as soon as they load in. See #1091.
2024-01-07 05:53:51 +01:00
game.old_mode_indicator_timer = game.mode_indicator_timer;
if (game.mode_indicator_timer > 0)
{
game.mode_indicator_timer -= 15;
}
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
// Editor ghosts!
if (game.ghostsenabled)
{
if (map.custommode && !map.custommodeforreal)
{
Remove game.gametimer in favor of game.frames PR #279 added game.gametimer solely for the editor ghosts feature. It seems that whoever originally wrote it (Leo for the now-dead VVVVVV: Community Edition, I believe) forgot that the game already had its own timer, that they could use. The game timer does increment on unfocus pause (whereas this doesn't), but that's a separate issue, and it ought to not do that.
2021-03-22 00:58:08 +01:00
if (game.frames % 3 == 0)
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
{
int i = obj.getplayer();
GhostInfo ghost;
ghost.rx = game.roomx-100;
ghost.ry = game.roomy-100;
if (INBOUNDS_VEC(i, obj.entities))
{
ghost.x = obj.entities[i].xp;
ghost.y = obj.entities[i].yp;
ghost.col = obj.entities[i].colour;
ghost.realcol = obj.entities[i].realcol;
ghost.frame = obj.entities[i].drawframe;
}
ed.ghosts.push_back(ghost);
}
if (ed.ghosts.size() > 100)
{
ed.ghosts.erase(ed.ghosts.begin());
}
}
}
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void titlerenderfixed(void)
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
{
if (!game.colourblindmode)
{
graphics.updatetowerbackground(graphics.titlebg);
}
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
{
titleupdatetextcol();
graphics.updatetitlecolours();
}
graphics.crewframedelay--;
if (graphics.crewframedelay <= 0)
{
graphics.crewframedelay = 8;
graphics.crewframe = (graphics.crewframe + 1) % 2;
}
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void maprenderfixed(void)
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
{
graphics.updatetextboxes();
graphics.updatetitlecolours();
graphics.crewframedelay--;
if (graphics.crewframedelay <= 0)
{
graphics.crewframedelay = 8;
graphics.crewframe = (graphics.crewframe + 1) % 2;
}
graphics.oldmenuoffset = graphics.menuoffset;
if (graphics.resumegamemode)
{
Fix bringing up map menu during gamemode(teleporter) When gamemode(teleporter) gets run in a script, it brings up a read-only version of the teleporter screen, intended only for displaying rooms on the minimap. However, ever since 2.3 allowed bringing up the map screen during cutscenes (in order to prevent softlocks), bringing up the map screen during this mode would (1) do an unnecessary animation of suddenly switching back to the game and bringing up the menu screen again (even though the menu screen has already been brought up), and (2) would let you close the menu entirely and go back to GAMEMODE, thus unintentionally closing the teleporter screen and kind of ruining the cutscene. To fix this, when you bring up the map screen, it will instead instantly transition to the map screen. And when you bring it down, it will also instantly transition back to the teleporter screen. But that's not all. The previous behavior was actually kind of a nice failsafe, in that if you somehow got stuck in a state where a script ran gamemode(teleporter), but stopped running before it could take you out of that mode by running gamemode(game), then you could return to GAMEMODE yourself by bringing up the map screen and then bringing it back down. So I've made sure to keep that failsafe behavior, only as long as there isn't a script running.
2020-12-29 00:36:32 +01:00
if (game.prevgamestate == GAMEMODE
//Failsafe: if the script command gamemode(teleporter) got ran and the
//cutscene stopped without doing gamemode(game), then we need to go
//back to GAMEMODE, not game.prevgamestate (TELEPORTERMODE)
|| !script.running)
{
graphics.menuoffset += 25;
Don't use `map.extrarow` for menu animations This fixes all the headaches about map.extrarow having to be the correct value and which way it should be and whatnot. The latest headache was the detection that prevent user-initiated menu animations while an animation was already happening being tripped because graphics.menuoffset would be 230 (due to closing the menu while being in a room without a room name), but then going to a room with a room name would check for 240 instead, and 230 is less than 240. (The numbers are the wrong way round because I got the ternaries the wrong way round, but even if the numbers are the correct way round, the bug would still happen, but it would just be reversed.) So instead, I've just made it 240 for both. This doesn't change the duration of the menu animation (because the animation moves in increments of 25, and 230 / 25 == 240 / 25 under integer division). It might change the animation slightly, but it was already inconsistent anyway because map.extrarow was always set to be 1 in custom levels, and I legitimately would not be able to tell the difference without recording the animations and nitpicking it frame-by-frame. Fixes #841.
2021-09-04 02:13:03 +02:00
int threshold = 240;
Fix bringing up map menu during gamemode(teleporter) When gamemode(teleporter) gets run in a script, it brings up a read-only version of the teleporter screen, intended only for displaying rooms on the minimap. However, ever since 2.3 allowed bringing up the map screen during cutscenes (in order to prevent softlocks), bringing up the map screen during this mode would (1) do an unnecessary animation of suddenly switching back to the game and bringing up the menu screen again (even though the menu screen has already been brought up), and (2) would let you close the menu entirely and go back to GAMEMODE, thus unintentionally closing the teleporter screen and kind of ruining the cutscene. To fix this, when you bring up the map screen, it will instead instantly transition to the map screen. And when you bring it down, it will also instantly transition back to the teleporter screen. But that's not all. The previous behavior was actually kind of a nice failsafe, in that if you somehow got stuck in a state where a script ran gamemode(teleporter), but stopped running before it could take you out of that mode by running gamemode(game), then you could return to GAMEMODE yourself by bringing up the map screen and then bringing it back down. So I've made sure to keep that failsafe behavior, only as long as there isn't a script running.
2020-12-29 00:36:32 +01:00
if (graphics.menuoffset >= threshold)
{
graphics.menuoffset = threshold;
//go back to gamemode!
game.mapheld = true;
game.gamestate = GAMEMODE;
Use `resumegamemode` to track menu animation This fixes a bug where the player could bring up the map on the very first frame of a gamemode(game) animation. This is because the menu animation checked graphics.menuoffset, but graphics.menuoffset wouldn't have changed at that point because it only set graphics.resumegamemode. Instead, just check for graphics.resumegamemode directly. We also need to assign it to false whenever the map is closed so the player won't be prevented from using the map screen again.
2021-09-06 01:59:05 +02:00
graphics.resumegamemode = false;
Fix bringing up map menu during gamemode(teleporter) When gamemode(teleporter) gets run in a script, it brings up a read-only version of the teleporter screen, intended only for displaying rooms on the minimap. However, ever since 2.3 allowed bringing up the map screen during cutscenes (in order to prevent softlocks), bringing up the map screen during this mode would (1) do an unnecessary animation of suddenly switching back to the game and bringing up the menu screen again (even though the menu screen has already been brought up), and (2) would let you close the menu entirely and go back to GAMEMODE, thus unintentionally closing the teleporter screen and kind of ruining the cutscene. To fix this, when you bring up the map screen, it will instead instantly transition to the map screen. And when you bring it down, it will also instantly transition back to the teleporter screen. But that's not all. The previous behavior was actually kind of a nice failsafe, in that if you somehow got stuck in a state where a script ran gamemode(teleporter), but stopped running before it could take you out of that mode by running gamemode(game), then you could return to GAMEMODE yourself by bringing up the map screen and then bringing it back down. So I've made sure to keep that failsafe behavior, only as long as there isn't a script running.
2020-12-29 00:36:32 +01:00
}
}
else
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
{
game.mapheld = true;
Fix bringing up map menu during gamemode(teleporter) When gamemode(teleporter) gets run in a script, it brings up a read-only version of the teleporter screen, intended only for displaying rooms on the minimap. However, ever since 2.3 allowed bringing up the map screen during cutscenes (in order to prevent softlocks), bringing up the map screen during this mode would (1) do an unnecessary animation of suddenly switching back to the game and bringing up the menu screen again (even though the menu screen has already been brought up), and (2) would let you close the menu entirely and go back to GAMEMODE, thus unintentionally closing the teleporter screen and kind of ruining the cutscene. To fix this, when you bring up the map screen, it will instead instantly transition to the map screen. And when you bring it down, it will also instantly transition back to the teleporter screen. But that's not all. The previous behavior was actually kind of a nice failsafe, in that if you somehow got stuck in a state where a script ran gamemode(teleporter), but stopped running before it could take you out of that mode by running gamemode(game), then you could return to GAMEMODE yourself by bringing up the map screen and then bringing it back down. So I've made sure to keep that failsafe behavior, only as long as there isn't a script running.
2020-12-29 00:36:32 +01:00
game.gamestate = game.prevgamestate;
graphics.resumegamemode = false;
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
}
}
else if (graphics.menuoffset > 0)
{
graphics.menuoffset -= 25;
if (graphics.menuoffset < 0)
{
graphics.menuoffset = 0;
}
}
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++;
}
Animated roomnames, setroomname command This commit adds a better system for animated roomnames. The old system, like many other systems, were very hardcoded, and can be described as mostly else-if chains, with some fun string comparisons. The new system uses lists of text for transformations and glitchy names, making it much easier to add new cases if needeed. This commit implements the system but does not replace the old system, where that is done in the next commit. The settings for special roomnames can be read from level XML, and `setroomname()` can be used from commands to set a new, static name.
2022-12-12 00:05:20 +01:00
map.updateroomnames();
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
}
Inline cutscene bars timer for gamemodes that used it in 2.2 As part of my work in #535, I've noticed that 2.3 currently with 2.2 loop order doesn't have interpolated cutscene bars. This is because cutscene bars in 2.3 get updated at the start of the frame, which interpolates them correctly until the render functions are put in their proper place. There is, however, a somewhat bigger issue, outside the scope of #535, where cutscene bars always get updated regardless of which gamemode you are in. Previously in 2.2 and previous, cutscene bars only got updated in GAMEMODE and TELEPORTERMODE; sometime during 2.3, the cutscene bars timer got pulled out of all the individual game modes and moved to the very start of the loop. (I was probably the one who did this change; I've been caught in a trap of my own devising.) Thus, going to MAPMODE during the cutscene bars animation doesn't keep their position paused like it would in 2.2. This is also categorically a more-than-visual change, since the untilbars() script command depends on the cutscene bars timer. I see no reason for the cutscene bars to behave differently in this way than 2.2; #535 would also end up doing the same fix more-or-less anyway. Since TELEPORTERMODE currently uses the same renderfixed function as MAPMODE, I've had to add a teleporterrenderfixed() that just calls maprenderfixed(), but also does the cutscene bars timer.
2021-03-17 08:28:47 +01:00
void teleporterrenderfixed(void)
{
maprenderfixed();
graphics.cutscenebarstimer();
}
Explicitly declare void for all void parameter functions (#628) Apparently in C, if you have `void test();`, it's completely okay to do `test(2);`. The function will take in the argument, but just discard it and throw it away. It's like a trash can, and a rude one at that. If you declare it like `void test(void);`, this is prevented. This is not a problem in C++ - doing `void test();` and `test(2);` is guaranteed to result in a compile error (this also means that right now, at least in all `.cpp` files, nobody is ever calling a void parameter function with arguments and having their arguments be thrown away). However, we may not be using C++ in the future, so I just want to lay down the precedent that if a function takes in no arguments, you must explicitly declare it as such. I would've added `-Wstrict-prototypes`, but it produces an annoying warning message saying it doesn't work in C++ mode if you're compiling in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
void gamecompleterenderfixed(void)
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
{
graphics.updatetitlecolours();
titleupdatetextcol();
Show skip prompt during credits and ending picture This adds a "- Press {button} to skip -" prompt to both the credits and ending picture sequences. It was always possible to skip them by pressing Enter, but not many people knew this. In fact, even I didn't know this until I saw Elomavi do it a year or so ago. So it's not really intuitive that this is possible. The prompt only shows up if you've completed the game before, and disappears after two seconds similar to the "[Press {button} to return to editor]" text. Unfortunately, given how the game works, game completion is detected based on if you have unlocked Flip Mode or not. At this point, the unlock for the game being completed (unlock 5) will already be set to true no matter what during the Plenary fanfare, but the Flip Mode unlock (unlock 18) won't be until the player hits "play" on the main menu. As a special case, the prompt will always show up in M&P (because Flip Mode is always unlocked in M&P).
2023-05-22 21:18:40 +02:00
tick_skip_message_timer();
}
void gamecompleterenderfixed2(void)
{
tick_skip_message_timer();
Move all fixed-timestep render updates to new file RenderFixed.cpp As part of fixing #464, I'll need to move these pieces of code around easily. In #220 I just kind of shoved them awkwardly in whatever fixed function would be last called in the gamestate loop, which I shouldn't have done as I've now had to make formal fixed-render functions anyway. Because these fixed functions need to be called directly before a render function, and I'm fixing the order to put render functions in their proper place, so I need to be able to move these around easily, and making them function calls instead of inlined makes them easier to manipulate.
2020-11-08 00:47:49 +01:00
}
Reference in a new issue Copy permalink