2020-01-01 21:29:24 +01:00
|
|
|
#ifndef MAPGAME_H
|
|
|
|
#define MAPGAME_H
|
|
|
|
|
|
|
|
#include <vector>
|
2022-12-12 00:05:20 +01:00
|
|
|
#include <string>
|
2020-07-19 21:05:41 +02:00
|
|
|
|
2020-07-19 21:43:29 +02:00
|
|
|
#include "Finalclass.h"
|
|
|
|
#include "Labclass.h"
|
|
|
|
#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;
|
2021-09-12 21:48:15 +02:00
|
|
|
const char* text;
|
2024-01-09 21:50:54 +01:00
|
|
|
bool rtl;
|
2020-07-06 21:37:04 +02:00
|
|
|
};
|
|
|
|
|
2022-12-12 00:05:20 +01:00
|
|
|
enum RoomnameType
|
|
|
|
{
|
2023-02-18 00:52:57 +01:00
|
|
|
RoomnameType_STATIC,
|
|
|
|
RoomnameType_GLITCH,
|
|
|
|
RoomnameType_TRANSFORM
|
2022-12-12 00:05:20 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct Roomname
|
|
|
|
{
|
|
|
|
int x;
|
|
|
|
int y;
|
|
|
|
bool loop;
|
|
|
|
int flag;
|
|
|
|
RoomnameType type;
|
|
|
|
std::vector<std::string> text;
|
|
|
|
int progress;
|
|
|
|
int delay;
|
|
|
|
};
|
|
|
|
|
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);
|
2022-12-01 07:35:42 +01:00
|
|
|
void destroy(void);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Unify all queries to map size to `map.getwidth` and `map.getheight`
It's becoming pretty clear that the size of the map is important enough
to be queried a lot, but each time it's something like `map.custommode ?
map.customwidth : 20` and `map.custommode ? map.customheight : 20` which
is not ideal because of copy-pasting.
Furthermore, even `map.customwidth` and `map.customheight` are just
duplicates of `cl.mapwidth` and `cl.mapheight`, which are only set in
`customlevelclass::generatecustomminimap`. This is a bit annoying if you
want to, say, add checks that depend on the width and height of the
custom map in `mapclass::initcustommapdata`, but `map.customwidth` and
`map.customheight` are out of date because `generatecustomminimap`
hasn't been called yet. And doing the ternary there requires a `#ifndef
NO_CUSTOM_LEVELS` to reference `cl.mapwidth` and `cl.mapheight` which is
just awful.
So I'm axing `map.customwidth` and `map.customheight`, and I'm axing all
the ternaries that are duplicating the source of truth in
`MapRenderData`. Instead, there will just be one function to call for
the width and height, `mapclass::getwidth` and `mapclass::getheight`,
and everyone can simply call those without needing to do ternaries or
duplication.
2022-11-30 22:35:14 +01:00
|
|
|
int getwidth(void);
|
|
|
|
|
|
|
|
int getheight(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
|
|
|
|
2022-12-01 07:35:42 +01:00
|
|
|
void setroomname(const char* name);
|
|
|
|
|
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
|
|
|
|
2023-08-23 22:03:23 +02:00
|
|
|
void fullmap(void);
|
|
|
|
|
2022-12-12 00:05:20 +01:00
|
|
|
void updateroomnames(void);
|
|
|
|
|
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
|
|
|
|
2023-02-18 00:52:57 +01:00
|
|
|
void roomnamechange(int x, int y, const char** lines, size_t size);
|
|
|
|
void roomnameglitch(int x, int y, const char* name, const char* glitch);
|
|
|
|
|
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);
|
|
|
|
|
2022-06-06 05:17:26 +02:00
|
|
|
bool towerspikecollide(int x, int y);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2022-06-06 05:17:26 +02:00
|
|
|
bool collide(int x, int y, bool invincible);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
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
|
|
|
|
2021-09-12 07:53:07 +02:00
|
|
|
void spawncompanion(void);
|
|
|
|
|
2023-09-12 00:07:10 +02:00
|
|
|
const char* currentarea(int roomx, int roomy);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
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-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);
|
|
|
|
|
2023-08-23 22:03:23 +02:00
|
|
|
bool revealmap;
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
int background;
|
|
|
|
int rcol;
|
|
|
|
int tileset;
|
|
|
|
bool warpx;
|
|
|
|
bool warpy;
|
|
|
|
|
|
|
|
|
2021-09-12 21:48:15 +02:00
|
|
|
const char* roomname;
|
2022-12-29 04:58:49 +01:00
|
|
|
bool roomname_special;
|
2022-12-12 00:05:20 +01:00
|
|
|
bool roomnameset;
|
2021-09-12 21:48:15 +02:00
|
|
|
const char* hiddenname;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2022-12-12 00:05:20 +01:00
|
|
|
std::vector<Roomname> specialroomnames;
|
|
|
|
|
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 custommmxoff, custommmyoff, custommmxsize, custommmysize;
|
|
|
|
int customzoom;
|
|
|
|
bool customshowmm;
|
|
|
|
|
|
|
|
//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
|
2023-01-29 08:32:14 +01:00
|
|
|
std::vector<SDL_Point> teleporters;
|
|
|
|
std::vector<SDL_Point> shinytrinkets;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
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 */
|