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

265 lines
6.5 KiB
C++
Raw Normal View History

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 "editor.h"
#include "Game.h"
#include "Graphics.h"
#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;
}
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();
}
if (map.finalmode)
{
map.glitchname = map.getglitchname(game.roomx, game.roomy);
}
#ifndef NO_CUSTOM_LEVELS
ed.oldreturneditoralpha = ed.returneditoralpha;
if (map.custommode && !map.custommodeforreal && ed.returneditoralpha > 0)
{
ed.returneditoralpha -= 15;
}
// 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;
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());
}
}
}
#endif
}
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;
int threshold = map.extrarow ? 230 : 240;
if (graphics.menuoffset >= threshold)
{
graphics.menuoffset = threshold;
//go back to gamemode!
game.mapheld = true;
game.gamestate = GAMEMODE;
}
}
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++;
}
if (map.finalmode)
{
map.glitchname = map.getglitchname(game.roomx, game.roomy);
}
}
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();
}
Reference in a new issue Copy permalink