2020-01-01 21:29:24 +01:00
|
|
|
#ifndef MAPGAME_H
|
|
|
|
|
#define MAPGAME_H
|
|
|
|
|
|
|
|
|
|
#include <vector>
|
2020-07-19 21:05:41 +02:00
|
|
|
|
2020-07-19 21:43:29 +02:00
|
|
|
#include "Finalclass.h"
|
|
|
|
|
#include "Labclass.h"
|
2020-07-19 21:05:41 +02:00
|
|
|
#include "Maths.h"
|
2020-07-19 21:43:29 +02:00
|
|
|
#include "Otherlevel.h"
|
|
|
|
|
#include "Spacestation2.h"
|
|
|
|
|
#include "Tower.h"
|
2020-11-03 00:05:24 +01:00
|
|
|
#include "TowerBG.h"
|
2020-07-19 21:43:29 +02:00
|
|
|
#include "WarpClass.h"
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-07-06 21:37:04 +02:00
|
|
|
struct Roomtext
|
|
|
|
|
{
|
|
|
|
|
int x, y;
|
|
|
|
|
std::string text;
|
|
|
|
|
};
|
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
class mapclass
|
|
|
|
|
{
|
|
|
|
|
public:
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
mapclass(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
int intpol(int a, int b, float c);
|
|
|
|
|
|
2020-04-15 04:29:19 +02:00
|
|
|
void setteleporter(int x, int y);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-04-15 04:37:00 +02:00
|
|
|
void settrinket(int x, int y);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void resetmap(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void resetnames(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
void transformname(int t);
|
|
|
|
|
|
|
|
|
|
std::string getglitchname(int x, int y);
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void initmapdata(void);
|
|
|
|
|
void initcustommapdata(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
int finalat(int x, int y);
|
|
|
|
|
|
|
|
|
|
int maptiletoenemycol(int t);
|
|
|
|
|
|
2020-03-31 10:09:42 +02:00
|
|
|
void changefinalcol(int t);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2021-01-08 02:37:38 +01:00
|
|
|
void setcol(TowerBG& bg_obj, const int r1, const int g1, const int b1 , const int r2, const int g2, const int b2, const int c);
|
|
|
|
|
|
|
|
|
|
void updatebgobj(TowerBG& bg_obj);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Consolidate tower BG bypos and bscroll assignments
Tower backgrounds have a bypos and bscroll. bypos is just the y-position
of the background, and bscroll is the amount of pixels to scroll the
background by on each frame, which is used to scroll it (if it's not
being redrawn) and for linear interpolation.
For the tower background (and not the title background), bypos is
map.ypos / 2, and bscroll is (map.ypos - map.oldypos) / 2. However,
usually bscroll gets assigned at the same time bypos is incremented or
decremented, so you never see that calculation explicitly - except in
the previous commit, where I worked out the calculation because the
change in y-position isn't a known constant.
Having to do all these calculations every time introduces the
possibility of errors where you forget to do it, or you do it wrongly.
But that's not even the worst; you could cause a linear interpolation
glitch if you decide to overwrite bscroll without taking into account
map.oldypos and map.ypos.
So that's why I'm adding a function that automatically updates the tower
background, using the values of map.oldypos and map.ypos, that is used
every time map.ypos is assigned. That way, we have to write less code,
you can be sure that there's no place where we forget to do the
calculations (or at least it will be glaringly obvious) or we do it
wrongly, and it plays nicely with linear interpolation. This also
replaces every instance where the manual calculations are done with the
new function.
2021-04-23 03:47:07 +02:00
|
|
|
void setbgobjlerp(TowerBG& bg_obj);
|
|
|
|
|
|
2020-11-03 00:05:24 +01:00
|
|
|
void updatetowerglow(TowerBG& bg_obj);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void nexttowercolour(void);
|
2021-08-06 01:38:06 +02:00
|
|
|
bool nexttowercolour_set;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
void settowercolour(int t);
|
|
|
|
|
|
|
|
|
|
bool spikecollide(int x, int y);
|
|
|
|
|
|
|
|
|
|
bool collide(int x, int y);
|
|
|
|
|
|
|
|
|
|
void settile(int xp, int yp, int t);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
int area(int _rx, int _ry);
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void exploretower(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void hideship(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void showship(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-12-28 22:16:16 +01:00
|
|
|
void resetplayer(const bool player_died);
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void resetplayer(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-03-31 10:09:42 +02:00
|
|
|
void warpto(int rx, int ry , int t, int tx, int ty);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-03-31 10:09:42 +02:00
|
|
|
void gotoroom(int rx, int ry);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
std::string currentarea(int t);
|
|
|
|
|
|
2020-03-31 10:09:42 +02:00
|
|
|
void loadlevel(int rx, int ry);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void twoframedelayfix(void);
|
Fix the two-frame-delay when entering a room with an "init" script
This patch is very kludge-y, but at least it fixes a semi-noticeable
visual issue in custom levels that use internal scripts to spawn
entities when loading a room.
Basically, the problem here is that when the game checks for script
boxes and sets newscript, newscript has already been processed for that
frame, and when the game does load a script, script.run() has already
been processed for that frame.
That issue can be fixed, but it turns out that due to my over-30-FPS
game loop changes, there's now ANOTHER visible frame of delay between
room load and entity creation, because the render function gets called
in between the script being loaded at the end of gamelogic() and the
script actually getting run.
So... I have to temporary move script.run() to the end of gamelogic()
(in map.twoframedelayfix()), and make sure it doesn't get run next
frame, because double-evaluations are bad. To do that, I have to
introduce the kludge variable script.dontrunnextframe, which does
exactly as it says.
And with all that work, the two-frame (now three-frame) delay is fixed.
2020-06-28 02:08:57 +02:00
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-07-03 06:01:09 +02:00
|
|
|
int roomdeaths[20 * 20];
|
|
|
|
|
int roomdeathsfinal[20 * 20];
|
2020-07-03 06:13:23 +02:00
|
|
|
static const int areamap[20 * 20];
|
2021-08-23 06:30:53 +02:00
|
|
|
int contents[40 * 30];
|
2020-07-03 06:01:09 +02:00
|
|
|
bool explored[20 * 20];
|
2020-07-03 11:06:46 +02:00
|
|
|
int vmult[30];
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2021-03-24 20:12:39 +01:00
|
|
|
bool isexplored(const int rx, const int ry);
|
|
|
|
|
void setexplored(const int rx, const int ry, const bool status);
|
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
int background;
|
|
|
|
|
int rcol;
|
|
|
|
|
int tileset;
|
|
|
|
|
bool warpx;
|
|
|
|
|
bool warpy;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
std::string roomname;
|
Refactor how "hidden names" work
By "hidden names", I'm referring to "Dimension VVVVVV" and "The Ship"
popping up on the quit/pause/teleporter screens, even though those rooms
don't have any roomnames.
Apparently my commit to fix roomname re-draw bleed on the
quit/pause/teleporter screens exposed yet another hardreset()-caused
bug. The issue here is that since hardreset() sets game.roomx and
game.roomy to 0, map.area() will no longer work properly, and since the
hidden roomname check is based on map.area(), it will no longer display
"Dimension VVVVVV" or "The Ship" once you press ACTION to quit. It used
to do this due to the re-draw bleed, but now it doesn't.
I saw that roomnames didn't get reset in hardreset(), so the solution
here is to re-factor hidden names to be an actual variable, instead of
being implicit. map.hiddenname is a variable that's set in
mapclass::loadlevel(), and if isn't empty, it will be drawn on the
quit/pause/teleporter screens. That way it will still display "Dimension
VVVVVV" and "The Ship" when you press ACTION to quit to the menu.
EDIT: Since PR #230 got merged, this commit is no longer strictly
necessary, but it's still good to refactor hidden names like this.
2020-05-02 23:10:22 +02:00
|
|
|
std::string hiddenname;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
//Special tower stuff
|
|
|
|
|
bool towermode;
|
2021-04-17 08:48:54 +02:00
|
|
|
int ypos;
|
|
|
|
|
int oldypos;
|
2020-01-01 21:29:24 +01:00
|
|
|
int cameramode;
|
|
|
|
|
int cameraseek, cameraseekframe;
|
|
|
|
|
int resumedelay;
|
|
|
|
|
bool minitowermode;
|
|
|
|
|
|
2020-11-03 00:05:24 +01:00
|
|
|
int colstatedelay;
|
2020-01-01 21:29:24 +01:00
|
|
|
int colsuperstate;
|
|
|
|
|
int spikeleveltop, spikelevelbottom;
|
2020-04-30 21:58:08 +02:00
|
|
|
int oldspikeleveltop, oldspikelevelbottom;
|
2020-01-01 21:29:24 +01:00
|
|
|
//final level navigation
|
|
|
|
|
bool finalmode;
|
|
|
|
|
bool finalstretch;
|
|
|
|
|
|
|
|
|
|
//Variables for playing custom levels
|
|
|
|
|
bool custommode;
|
|
|
|
|
bool custommodeforreal;
|
|
|
|
|
int customwidth, customheight;
|
|
|
|
|
int custommmxoff, custommmyoff, custommmxsize, custommmysize;
|
|
|
|
|
int customzoom;
|
|
|
|
|
bool customshowmm;
|
|
|
|
|
|
2020-07-03 11:33:33 +02:00
|
|
|
std::string specialnames[8];
|
2020-01-01 21:29:24 +01:00
|
|
|
int glitchmode;
|
|
|
|
|
int glitchdelay;
|
|
|
|
|
std::string glitchname;
|
|
|
|
|
|
|
|
|
|
//final level colour cycling stuff
|
|
|
|
|
bool final_colormode;
|
|
|
|
|
int final_mapcol;
|
|
|
|
|
int final_aniframe;
|
|
|
|
|
int final_aniframedelay;
|
|
|
|
|
int final_colorframe, final_colorframedelay;
|
|
|
|
|
|
|
|
|
|
//Teleporters and Trinkets on the map
|
|
|
|
|
std::vector<point> teleporters;
|
|
|
|
|
std::vector<point> shinytrinkets;
|
|
|
|
|
|
|
|
|
|
bool showteleporters, showtargets, showtrinkets;
|
|
|
|
|
|
|
|
|
|
//Roomtext
|
|
|
|
|
bool roomtexton;
|
Refactor roomtext to not use ad-hoc objects / separate length trackers
This refactors the roomtext code to (1) not use ad-hoc objects and (2)
not use a separate length-tracking variable to keep track of the actual
amount of roomtext in a room.
What I mean by ad-hoc object is, instead of formally creating a
fully-fledged struct or class and storing one vector containing that
object, this game instead hacks together an object by storing each
attribute of an object in different vectors.
In the case of roomtext, instead of making a Roomtext object that has
attributes 'x', 'y', and 'text', the 'text' attribute of each is stored
in the vector 'roomtext', the 'x' attribute of each is stored in the
vector 'roomtextx', and the 'y' attribute of each is stored in the
vector 'roomtexty'. It's only an object in the sense that you can grab
the attributes of each roomtext by using the same index across all three
vectors.
This makes it somewhat annoying to maintain and deal with, like when I
wanted add sub-tile positions to roomtext in VVVVVV: Community Edition.
Instead of being able to add attributes to an already-existing
formalized Roomtext object, I would instead have to add two more
vectors, which is inelegant. Or I could refactor the whole system, which
is what I decided to do instead.
Furthermore, this removes the separate length-tracking variable
'roomtextnumlines', which makes the code much more easy to maintain and
deal with, as the amount of roomtext is naturally tracked by C++ instead
of us having to keep track of the actual amount of roomtext manually.
2020-03-01 03:26:12 +01:00
|
|
|
std::vector<Roomtext> roomtext;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
//Levels
|
|
|
|
|
otherlevelclass otherlevel;
|
|
|
|
|
spacestation2class spacestation2;
|
|
|
|
|
labclass lablevel;
|
|
|
|
|
finalclass finallevel;
|
|
|
|
|
warpclass warplevel;
|
|
|
|
|
towerclass tower;
|
|
|
|
|
int extrarow;
|
|
|
|
|
|
|
|
|
|
//Accessibility options
|
|
|
|
|
bool invincibility;
|
|
|
|
|
|
|
|
|
|
//Map cursor
|
|
|
|
|
int cursorstate, cursordelay;
|
|
|
|
|
};
|
|
|
|
|
|
2020-09-28 04:15:06 +02:00
|
|
|
#ifndef MAP_DEFINITION
|
Allow using help/graphics/music/game/key/map/obj everywhere
This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and
`obj` essentially static global objects that can be used everywhere.
This is useful in case we ever need to add a new function in the future,
so we don't have to bother with passing a new argument in which means we
have to pass a new argument in to the function that calls that function
which means having to pass a new argument into the function that calls
THAT function, etc. which is a real headache when working on fan mods of
the source code.
Note that this changes NONE of the existing function signatures, it
merely just makes those variables accessible everywhere in the same way
`script` and `ed` are.
Also note that some classes had to be initialized after the filesystem
was initialized, but C++ would keep initializing them before the
filesystem got initialized, because I *had* to put them at the top of
`main.cpp`, or else they wouldn't be global variables.
The only way to work around this was to use entityclass's initialization
style (which I'm pretty sure entityclass of all things doesn't need to
be initialized this way), where you actually initialize the class in an
`init()` function, and so then you do `graphics.init()` after the
filesystem initialization, AFTER doing `Graphics graphics` up at the
top.
I've had to do this for `graphics` (but only because its child
GraphicsResources `grphx` needs to be initialized this way), `music`,
and `game`. I don't think this will affect anything. Other than that,
`help`, `key`, and `map` are still using the C++-intended method of
having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
|
|
|
extern mapclass map;
|
2020-09-28 04:15:06 +02:00
|
|
|
#endif
|
Allow using help/graphics/music/game/key/map/obj everywhere
This commit makes `help`, `graphics`, `music`, `game`, `key`, `map`, and
`obj` essentially static global objects that can be used everywhere.
This is useful in case we ever need to add a new function in the future,
so we don't have to bother with passing a new argument in which means we
have to pass a new argument in to the function that calls that function
which means having to pass a new argument into the function that calls
THAT function, etc. which is a real headache when working on fan mods of
the source code.
Note that this changes NONE of the existing function signatures, it
merely just makes those variables accessible everywhere in the same way
`script` and `ed` are.
Also note that some classes had to be initialized after the filesystem
was initialized, but C++ would keep initializing them before the
filesystem got initialized, because I *had* to put them at the top of
`main.cpp`, or else they wouldn't be global variables.
The only way to work around this was to use entityclass's initialization
style (which I'm pretty sure entityclass of all things doesn't need to
be initialized this way), where you actually initialize the class in an
`init()` function, and so then you do `graphics.init()` after the
filesystem initialization, AFTER doing `Graphics graphics` up at the
top.
I've had to do this for `graphics` (but only because its child
GraphicsResources `grphx` needs to be initialized this way), `music`,
and `game`. I don't think this will affect anything. Other than that,
`help`, `key`, and `map` are still using the C++-intended method of
having ClassName::ClassName() functions.
2020-01-29 08:35:03 +01:00
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
#endif /* MAPGAME_H */
|
