mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-11-17 16:39:42 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/Graphics.h

370 lines
8 KiB
C
Raw Normal View History

Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#ifndef GRAPHICS_H
#define GRAPHICS_H
Add support for Unicode rendering (#47) This uses utfcpp combined with a custom font, in the form of a PNG and text file. By default, the game acts exactly as it did before; custom fonts can be provided by third parties.
2020-01-31 19:25:37 +01:00
#include <map>
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include <string>
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include <vector>
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "GraphicsResources.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "GraphicsUtil.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "Maths.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "Screen.h"
Separate includes into sections and alphabetize them Okay, so basically here's the include layout that this game now consistently uses: [The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)] [blank line] [All system includes, such as tinyxml2/physfs/utfcpp/SDL] [blank line] [All project includes, such as Game.h/Entity.h/etc.] And if applicable, another blank line, and then some special-case include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp, for example, they have ifdefs and defines with their includes).
2020-07-19 21:43:29 +02:00
#include "Textbox.h"
Refactor tower background to use a separate object instead Previously, the tower background was controlled by a disparate set of attributes on Graphics and mapclass, and wasn't really encapsulated. (If that's what that word means, I don't particularly care about object-oriented lingo.) But now, all relevant things that a tower background has has been put into a TowerBG struct, so it will be easy to make multiple copies without having to duplicate the code that handles it.
2020-11-03 00:05:24 +01:00
#include "TowerBG.h"
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
class Graphics
{
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
void init(void);
void destroy(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Move Graphics buffer creation to new func create_buffers() It doesn't feel quite write leaving all the buffer creation code in main(), even though it's perfectly okay to do so and it doesn't result in any memory mismanagement that Valgrind can report; so I'm factoring all of it out to a separate function, Graphics::create_buffers(). As a bonus, we no longer have to keep qualifying with `graphics.` in the buffer creation code, which is nice.
2021-02-16 01:18:45 +01:00
void create_buffers(const SDL_PixelFormat* fmt);
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 destroy_buffers(void);
Add Graphics::destroy_buffers() These destroy all the buffers that are created on the Graphics class. Since these buffers can't be created at the same time as the rest of Graphics is (due to the fact that they require knowing the pixel format of the game screen), they can't be destroyed at the same as the rest of Graphics is, either.
2021-02-16 01:16:52 +01:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
GraphicsResources grphx;
Use uint32_t instead of char32_t
2020-02-11 06:48:07 +01:00
int bfontlen(uint32_t ch);
int font_idx(uint32_t ch);
Add support for Unicode rendering (#47) This uses utfcpp combined with a custom font, in the form of a PNG and text file. By default, the game acts exactly as it did before; custom fonts can be provided by third parties.
2020-01-31 19:25:37 +01:00
Do not close game if custom level has assets issues It's quite rude to close the game entirely if there is trouble with assets. Instead, just unload the assets and gracefully return to the title screen.
2021-08-07 05:57:34 +02:00
bool Makebfont(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Move setcol part of drawhuetile() to separate function In order to make sure colors don't update more than 1000/34 frames per second, I'll have to move the color-setting part of this function somewhere else.
2020-04-30 23:42:08 +02:00
void drawhuetile(int x, int y, int t);
void huetilesetcol(int t);
Move big chunky pixel colors to separate function Again, to make sure colors don't update more than 1000/34 frames a second, we'll need to separate this color calculation from rendeirng functions.
2020-04-30 23:57:21 +02:00
Uint32 bigchunkygetcol(int t);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove global args from Graphics This removes global args from all functions on the Graphics class. Callers of those functions in other files have been updated accordingly. Of course, since Graphics.cpp is already in the Graphics namespace, I do not need to change all 'dwgfx' to 'graphics' in Graphics.cpp.
2020-03-31 21:26:11 +02:00
void drawgravityline(int t);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Do not close game if custom level has assets issues It's quite rude to close the game entirely if there is trouble with assets. Instead, just unload the assets and gracefully return to the title screen.
2021-08-07 05:57:34 +02:00
bool MakeTileArray(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Do not close game if custom level has assets issues It's quite rude to close the game entirely if there is trouble with assets. Instead, just unload the assets and gracefully return to the title screen.
2021-08-07 05:57:34 +02:00
bool MakeSpriteArray(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Do not close game if custom level has assets issues It's quite rude to close the game entirely if there is trouble with assets. Instead, just unload the assets and gracefully return to the title screen.
2021-08-07 05:57:34 +02:00
bool maketelearray(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void drawcoloredtile(int x, int y, int t, int r, int g, int b);
De-duplicate Graphics::drawmenu() and Graphics::drawlevelmenu() Graphics::drawmenu() no longer has copy-pasted code for each individual case. Instead, the individual cases have their own adding on to common code, which is far easier to maintain. Also, the only difference Graphics::drawlevelmenu() does is in some y-positioning stuff. There's no reason to make it a whole separate function and duplicate everything AGAIN. So it's been consolidated into Graphics::drawmenu() as well, and I've added a boolean to draw a menu this way if it's the level menu.
2020-07-04 23:53:05 +02:00
void drawmenu(int cr, int cg, int cb, bool levelmenu = false);
Hello WWWWWWorld!
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 processfade(void);
Ensure oldfadeamount is updated when fadeamount is Like cutscene bars, I've added Graphics::setfade(), to ensure that no deltaframe rendering glitches happen due to oldfadeamount not being updated properly. And indeed, this fixes a deltaframe rendering glitch that happens if you return to the editor from playtesting on a faded-out screen, then fade out again (by either re-entering playtesting and then cause a fadeout to happen again, or by quitting from the editor afterwards). The same glitch also happens outside of in-editor playtesting if you exit to the menu while the screen is faded out.
2021-03-20 07:09:11 +01:00
void setfade(const int amount);
Hello WWWWWWorld!
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 drawfade(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void setwarprect(int a, int b, int c, int d);
Add createtextboxreal() and createtextboxflipme() createtextboxreal() is the same as createtextbox(), but with a flipme parameter added to create text boxes that have their flipme attribute set to true. createtextbox() just calls createtextboxreal() with flipme set to false, and createtextboxflipme() just calls createtextboxreal() with flipme set to true; this is because I do not want to use C++ function overloading.
2021-03-20 04:03:08 +01:00
void createtextboxreal(
std::string t,
int xp,
int yp,
int r,
int g,
int b,
bool flipme
);
void createtextbox(
std::string t,
int xp,
int yp,
int r,
int g,
int b
);
void createtextboxflipme(
std::string t,
int xp,
int yp,
int r,
int g,
int b
);
Hello WWWWWWorld!
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 textboxcenterx(void);
Hello WWWWWWorld!
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
int textboxwidth(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void textboxmoveto(int xo);
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 textboxcentery(void);
Hello WWWWWWorld!
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 textboxadjust(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void addline(std::string t);
void textboxtimer(int t);
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 textboxremove(void);
Hello WWWWWWorld!
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 textboxremovefast(void);
Hello WWWWWWorld!
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 textboxactive(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void drawtextbox(int x, int y, int w, int h, int r, int g, int b);
void drawpixeltextbox(int x, int y, int w, int h, int w2, int h2, int r, int g, int b, int xo, int yo);
void drawcustompixeltextbox(int x, int y, int w, int h, int w2, int h2, int r, int g, int b, int xo, int yo);
Remove global args from Graphics This removes global args from all functions on the Graphics class. Callers of those functions in other files have been updated accordingly. Of course, since Graphics.cpp is already in the Graphics namespace, I do not need to change all 'dwgfx' to 'graphics' in Graphics.cpp.
2020-03-31 21:26:11 +02:00
void drawcrewman(int x, int y, int t, bool act, bool noshift =false);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int crewcolour(const int t);
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 cutscenebars(void);
void cutscenebarstimer(void);
Ensure oldcutscenebars is updated when cutscenebarspos is To do this, I've added Graphics::setbars(), to make sure oldcutscenebarspos always gets assigned when cutscenebarspos is. This fixes potential deltaframe rendering issues if these two mismatch.
2021-03-20 07:08:35 +01:00
void setbars(const int position);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void drawpartimage(int t, int xp, int yp, int wp, int hp);
void drawimage(int t, int xp, int yp, bool cent=false);
void drawimagecol(int t, int xp, int yp, int r, int g, int b, bool cent= false);
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 updatetextboxes(void);
void drawgui(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void drawsprite(int x, int y, int t, int r, int g, int b);
Fix colors updating too fast in TITLEMODE/MAPMODE/GAMECOMPLETEMODE These colors were of the colors of each crewmate, the inactive crewmate color, and the color of the trinket and clock on the quicksave/summary screens. These colors all used fRandom() and so kept updating too quickly because they would be recalculated every time the delta-timestep render function got called, which isn't ideal. Thus, I've had to add attributes onto the Graphics class to store these colors and make sure they're only recalculated in logic functions instead. Thankfully, the color used for the sprites on the time trial results screen doesn't use fRandom(), so I don't have to worry about those. There's a new version of Graphics::drawsprite() that takes in a pre-made color already, instead of a color ID. As well, I've also added Graphics::updatetitlecolours() to update these colors on the title screen.
2020-05-02 01:40:35 +02:00
void drawsprite(int x, int y, int t, Uint32 c);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void printcrewname(int x, int y, int t);
void printcrewnamestatus(int x, int y, int t);
void printcrewnamedark(int x, int y, int t);
Add Graphics::map_tab() This function is useful to de-duplicate all the map page names at the bottom, which are MAP, CREW/SHIP/GRAV, STATS, and SAVE. If selected, it will surround the text in square brackets and automatically handle the positioning. Shamelessly copy-pasted from Dav999's localization branch.
2020-06-21 03:33:55 +02:00
void map_tab(int opt, const std::string& text, bool selected = false);
Add Graphics::map_option() Similar to Graphics::map_tab(), this ensures that I don't have to copy-paste printing the map options for every single game.menupage case I want, and in this case that's a good thing because there'll be 4 game.menupage cases I'll be using.
2020-06-23 00:23:15 +02:00
void map_option(int opt, int num_opts, const std::string& text, bool selected = false);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void Print(int _x, int _y, std::string _s, int r, int g, int b, bool cen = false);
Make "[Press ENTER to return to editor]" fade out after a bit This makes the "[Press ENTER to return to editor]" fade out after a few frames, allowing screenshots of custom levels to be cleaner and to make sure nothing is obscured while the user is editing their level. This commit also adds alpha support in BlitSurfaceColoured, where it takes into account the alpha of the pixel *and* the alpha of the color. `graphics::getRGBA(r,g,b,a)` was added to help with this.
2020-02-10 03:23:12 +01:00
void PrintAlpha(int _x, int _y, std::string _s, int r, int g, int b, int a, bool cen = false);
Add graphics wrapping functions This will wrap text on-the-fly, since I will be introducing text that needs to be wrapped whose length we can't know in advance. (Or we can, but, that'd be stupid.) I took the algorithm from Dav999's localization branch, but it's not like it's a complicated algorithm in the first place. Plus I think it actually handles words that get too long to fit on a single line better than his localization branch. The only difference is that I removed all the STL, and made it more memory efficient (unlike his localization branch, it does not copy the entire string to make a version with newline separator characters).
2021-08-07 05:55:09 +02:00
bool next_wrap(size_t* start, size_t* len, const char* str, int maxwidth);
bool next_wrap_s(char buffer[], size_t buffer_size, size_t* start, const char* str, int maxwidth);
void PrintWrap(int x, int y, const char* str, int r, int g, int b, bool cen, int linespacing, int maxwidth);
Make "[Press ENTER to return to editor]" fade out after a bit This makes the "[Press ENTER to return to editor]" fade out after a few frames, allowing screenshots of custom levels to be cleaner and to make sure nothing is obscured while the user is editing their level. This commit also adds alpha support in BlitSurfaceColoured, where it takes into account the alpha of the pixel *and* the alpha of the color. `graphics::getRGBA(r,g,b,a)` was added to help with this.
2020-02-10 03:23:12 +01:00
void PrintOffAlpha(int _x, int _y, std::string _s, int r, int g, int b, int a, bool cen = false);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void bprint(int x, int y, std::string t, int r, int g, int b, bool cen = false);
Make "[Press ENTER to return to editor]" fade out after a bit This makes the "[Press ENTER to return to editor]" fade out after a few frames, allowing screenshots of custom levels to be cleaner and to make sure nothing is obscured while the user is editing their level. This commit also adds alpha support in BlitSurfaceColoured, where it takes into account the alpha of the pixel *and* the alpha of the color. `graphics::getRGBA(r,g,b,a)` was added to help with this.
2020-02-10 03:23:12 +01:00
void bprintalpha(int x, int y, std::string t, int r, int g, int b, int a, bool cen = false);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int len(std::string t);
void bigprint( int _x, int _y, std::string _s, int r, int g, int b, bool cen = false, int sc = 2 );
Add Graphics::bigbprint() It's just like bigprint() except it duplicates some of the calculations because I didn't want to make a bigprintoff() function which would duplicate even more code. I'm beginning to think these text printing functions are completely horrible to work with...
2021-03-19 22:26:59 +01:00
void bigbprint(int x, int y, std::string s, int r, int g, int b, bool cen = false, int sc = 2);
Remove global args from Graphics This removes global args from all functions on the Graphics class. Callers of those functions in other files have been updated accordingly. Of course, since Graphics.cpp is already in the Graphics namespace, I do not need to change all 'dwgfx' to 'graphics' in Graphics.cpp.
2020-03-31 21:26:11 +02:00
void drawspritesetcol(int x, int y, int t, int c);
Hello WWWWWWorld!
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 flashlight(void);
void screenshake(void);
void updatescreenshake(void);
Update screenshake position in fixed-timestep loop Otherwise the screen will shake too fast for my liking. Also I'm planning to add an FPS limiting option later (because right now, un-capping the FPS is pretty wasteful and eats up lots of resources, especially since I have only a 60hz monitor), and it'd feel weird if screen shaking updated every delta timestep.
2020-04-29 02:29:59 +02:00
int screenshake_x;
int screenshake_y;
Hello WWWWWWorld!
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 render(void);
void renderwithscreeneffects(void);
Fix filter/screenshake/flash update order In 2.2, at render time, the game rendered screenshakes and flashes if their timers were above 0, and then decremented them afterwards. The game would also update the analogue filter right before rendering it, too. In 2.3, this was changed so the flash and screenshake timers were unified, and also done at the end of the frame - right before rendering happened. This resulted in 1-frame flashes and screenshakes not rendering at all. The other changes in this patchset don't fix this either. The analogue filter was also in the wrong order, but that is less of an issue than flashes and screenshakes. So, what I've done is made the flash and screenshake timers update right before the loop switches over to rendering, and only decrements them when we switch back to fixed functions (after rendering). The analogue filter is also updated right before rendering as well. This restores 1-frame flashes and screenshakes, as well as restores the correct order of analogue filter updates.
2021-03-18 01:53:17 +01:00
void renderfixedpre(void);
void renderfixedpost(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove unused arguments from Graphics::Hitest() The two arguments 'col' and 'col2', both the only integer arguments of the function, do absolutely nothing. Remove those and update callers.
2020-04-02 00:35:27 +02:00
bool Hitest(SDL_Surface* surface1, point p1, SDL_Surface* surface2, point p2);
Hello WWWWWWorld!
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 drawentities(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Factor out entity drawing to separate function This makes it easy to re-use without duplicating code.
2020-11-01 05:38:15 +01:00
void drawentity(const int i, const int yoff);
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 drawtrophytext(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void bigrprint(int x, int y, std::string& t, int r, int g, int b, bool cen = false, float sc = 2);
Add Graphics::bigrprint() Same as bigbprint(), we duplicate some of the calculations because it's better than duplicating another text printing function.
2021-03-19 22:28:04 +01:00
void bigbrprint(int x, int y, std::string& t, int r, int g, int b, bool cen = false, float sc = 2);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Fix, for in-GAMEMODE sprites, their colors updating too fast Okay, so the problem here is that Graphics::setcol() is called right before a sprite is drawn in a render function, but render functions are done in deltatime, meaning that the color of a sprite keeps being recalculated every time. This only affects sprites that use fRandom() (the other thing that can dynamically determine a color is help.glow, but that's only updated in the fixed-timestep loop), but is especially noticeable for sprites that flash wildly, like the teleporter, trinket, and elephant. To fix this, we need to make the color be recalculated only in the fixed-timestep loop. However, this means that we MUST store the color of the sprite SOMEWHERE for the delta-timesteps to render it, otherwise the color calculation will just be lost or something. So each entity now has a new attribute, `realcol`, which is the actual raw color used to render the sprite in render functions. This is not to be confused with their `colour` attribute, which is more akin to a color "ID" of sorts, but which isn't an actual color. At the end of gamelogic(), as well as when an entity is first created, the `colour` is given to Graphics::setcol() and then `realcol` gets set to the actual color. Then when it comes time to render the entity, `realcol` gets used instead. Gravitron squares are a somewhat tricky case where there's technically TWO colors for it - one is the actual sprite itself and the other is the indicator. However, usually the indicator and the square aren't both onscreen at the same time, so we can simply switch the realcol between the two as needed. However, we can't use this system for the sprite colors used on the title and map screen, so we'll have to do something else for those.
2020-05-01 02:34:37 +02:00
void drawtele(int x, int y, int t, Uint32 c);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Make "[Press ENTER to return to editor]" fade out after a bit This makes the "[Press ENTER to return to editor]" fade out after a few frames, allowing screenshots of custom levels to be cleaner and to make sure nothing is obscured while the user is editing their level. This commit also adds alpha support in BlitSurfaceColoured, where it takes into account the alpha of the pixel *and* the alpha of the color. `graphics::getRGBA(r,g,b,a)` was added to help with this.
2020-02-10 03:23:12 +01:00
Uint32 getRGBA(Uint8 r, Uint8 g, Uint8 b, Uint8 a);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Uint32 getRGB(Uint8 r, Uint8 g, Uint8 b);
Uint32 getBGR(Uint8 r, Uint8 g, Uint8 b);
Uint32 getRGB(Uint32 _col);
Uint32 RGBflip(Uint8 r, Uint8 g, Uint8 b);
Uint32 RGBf(int r, int g, int b);
void setcolreal(Uint32 t);
Remove global args from Graphics This removes global args from all functions on the Graphics class. Callers of those functions in other files have been updated accordingly. Of course, since Graphics.cpp is already in the Graphics namespace, I do not need to change all 'dwgfx' to 'graphics' in Graphics.cpp.
2020-03-31 21:26:11 +02:00
void drawbackground(int t);
Update left-moving star BG in fixed timestep loop Otherwise they will move too fast.
2020-04-29 04:28:16 +02:00
void updatebackground(int t);
De-duplicate one-way recolor conditional Now you only have to call one function (and pass it a tile number) to figure out if you should recolor a one-way tile or not, and you don't have to copy-paste.
2021-03-06 08:55:35 +01:00
#ifndef NO_CUSTOM_LEVELS
Make one-way recolors check for specific files So, 2.3 added recoloring one-way tiles to no longer make them be always yellow. However, custom levels that retexture the one-way tiles might not want them to be recolored. So, if there are ANY custom assets mounted, then the one-ways will not be recolored. However, if the XML has a <onewaycol_override>1</onewaycol_override> tag, then the one-way will be recolored again anyways. When I added one-way recoloring, I didn't intend for any custom asset to disable the recoloring; I only did it because I couldn't find a way to check if a specific file was customized by the custom level or not. However, I have figured out how to do so, and so now tiles.png one-way recolors will only be disabled if there's a custom tiles.png, and tiles2.png one-way recolors will only be disabled if there's a custom tiles2.png. In order to make sure we're not calling PhysFS functions on every single deltaframe, I've added caching variables, tiles1_mounted and tiles2_mounted, to Graphics; these get assigned every time reloadresources() is called.
2021-03-06 19:52:11 +01:00
bool shouldrecoloroneway(const int tilenum, const bool mounted);
De-duplicate one-way recolor conditional Now you only have to call one function (and pass it a tile number) to figure out if you should recolor a one-way tile or not, and you don't have to copy-paste.
2021-03-06 08:55:35 +01:00
#endif
Crop bottom tower spikes so they don't get drawn behind room name If you have the translucent room name option enabled, you'd always be seeing the spikes at the bottom of the screen hidden behind the room name. This patch makes it so that the spikes get carefully cropped so they only appear above the room name when the player gets close to the bottom of the screen.
2020-08-04 04:13:08 +02:00
void drawtile3( int x, int y, int t, int off, int height_subtract = 0 );
Remove unused arguments from Graphics::drawtile2() The 'r', 'g', and 'b' arguments do absolutely nothing. Except unlike Graphics::drawtile(), there's only one version of Graphics::drawtile2(), so just remove those args and update callers.
2020-04-02 00:47:35 +02:00
void drawtile2( int x, int y, int t );
Remove unused arguments from Graphics::drawtile() The 'r', 'g', and 'b' arguments do absolutely nothing, even though they're used in the version of Graphics::drawtile() that's more used. So delete the other version without those extra arguments, and then remove the extra arguments from the remaining version. And then update callers.
2020-04-02 00:42:22 +02:00
void drawtile( int x, int y, int t );
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void drawtowertile( int x, int y, int t );
Refactor tower background to use a separate object instead Previously, the tower background was controlled by a disparate set of attributes on Graphics and mapclass, and wasn't really encapsulated. (If that's what that word means, I don't particularly care about object-oriented lingo.) But now, all relevant things that a tower background has has been put into a TowerBG struct, so it will be easy to make multiple copies without having to duplicate the code that handles it.
2020-11-03 00:05:24 +01:00
void drawtowertile3( int x, int y, int t, TowerBG& bg_obj );
Hello WWWWWWorld!
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 drawmap(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
void drawforetile(int x, int y, int t);
void drawforetile2(int x, int y, int t);
void drawforetile3(int x, int y, int t, int off);
void drawrect(int x, int y, int w, int h, int r, int g, int b);
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 drawtowermap(void);
Hello WWWWWWorld!
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 drawtowerspikes(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
bool onscreen(int t);
Remove a trailing whitespace from Graphics.h Don't know why this was here, or how.
2020-06-12 02:56:12 +02:00
Do not close game if custom level has assets issues It's quite rude to close the game entirely if there is trouble with assets. Instead, just unload the assets and gracefully return to the title screen.
2021-08-07 05:57:34 +02:00
bool reloadresources(void);
Make one-way recolors check for specific files So, 2.3 added recoloring one-way tiles to no longer make them be always yellow. However, custom levels that retexture the one-way tiles might not want them to be recolored. So, if there are ANY custom assets mounted, then the one-ways will not be recolored. However, if the XML has a <onewaycol_override>1</onewaycol_override> tag, then the one-way will be recolored again anyways. When I added one-way recoloring, I didn't intend for any custom asset to disable the recoloring; I only did it because I couldn't find a way to check if a specific file was customized by the custom level or not. However, I have figured out how to do so, and so now tiles.png one-way recolors will only be disabled if there's a custom tiles.png, and tiles2.png one-way recolors will only be disabled if there's a custom tiles2.png. In order to make sure we're not calling PhysFS functions on every single deltaframe, I've added caching variables, tiles1_mounted and tiles2_mounted, to Graphics; these get assigned every time reloadresources() is called.
2021-03-06 19:52:11 +01:00
#ifndef NO_CUSTOM_LEVELS
bool tiles1_mounted;
bool tiles2_mounted;
Draw minimap.png if it is mounted This is a simple change - we draw minimap.png, instead of the generated custom map, if it is a per-level mounted custom asset. Custom levels have already been able to utilize minimap.png, but it was limited - they could do gamemode(teleporter) in a script, and that would show their customized minimap.png, but it's not like the player could look at it during gameplay. I would have done this earlier if I had figured out how to check if a specific asset was mounted or not.
2021-04-19 08:39:10 +02:00
bool minimap_mounted;
Make one-way recolors check for specific files So, 2.3 added recoloring one-way tiles to no longer make them be always yellow. However, custom levels that retexture the one-way tiles might not want them to be recolored. So, if there are ANY custom assets mounted, then the one-ways will not be recolored. However, if the XML has a <onewaycol_override>1</onewaycol_override> tag, then the one-way will be recolored again anyways. When I added one-way recoloring, I didn't intend for any custom asset to disable the recoloring; I only did it because I couldn't find a way to check if a specific file was customized by the custom level or not. However, I have figured out how to do so, and so now tiles.png one-way recolors will only be disabled if there's a custom tiles.png, and tiles2.png one-way recolors will only be disabled if there's a custom tiles2.png. In order to make sure we're not calling PhysFS functions on every single deltaframe, I've added caching variables, tiles1_mounted and tiles2_mounted, to Graphics; these get assigned every time reloadresources() is called.
2021-03-06 19:52:11 +01:00
#endif
Hello WWWWWWorld!
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 menuoffrender(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Refactor tower background to use a separate object instead Previously, the tower background was controlled by a disparate set of attributes on Graphics and mapclass, and wasn't really encapsulated. (If that's what that word means, I don't particularly care about object-oriented lingo.) But now, all relevant things that a tower background has has been put into a TowerBG struct, so it will be easy to make multiple copies without having to duplicate the code that handles it.
2020-11-03 00:05:24 +01:00
void drawtowerbackground(const TowerBG& bg_obj);
void updatetowerbackground(TowerBG& bg_obj);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove global args from Graphics This removes global args from all functions on the Graphics class. Callers of those functions in other files have been updated accordingly. Of course, since Graphics.cpp is already in the Graphics namespace, I do not need to change all 'dwgfx' to 'graphics' in Graphics.cpp.
2020-03-31 21:26:11 +02:00
void setcol(int t);
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 drawfinalmap(void);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
colourTransform ct;
Move temporary bcol/bcol2 off of Graphics Looks like I had missed yet another two temporary variables that were actually globals on the Graphics class. Glad I caught these ones.
2020-11-02 22:02:51 +01:00
int rcol;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Remove i/j/k attributes from classes that don't need them The only class that actually needs its i/j/k kept is scriptclass, because some custom levels rely on it for creating custom activity zones. So I haven't touched that. Other than that, there's no chance that anything important relies on i/j/k in any other class. For that to be the case, it would have to use i/j/k without initializing it beforehand, and that can simply be detected by removing the attribute from the header file and seeing where the compiler complains. And the compiler complains only about cases where it's initialized first. (Note that due to this check, I *haven't* removed Graphics's `m` as it precisely does exactly this, using it without initializing it first.) Interestingly enough, otherlevelclass and towerclass have unused i/k variables for whatever reason.
2020-06-14 20:21:32 +02:00
int m;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
std::vector <SDL_Surface*> images;
std::vector <SDL_Surface*> tele;
std::vector <SDL_Surface*> tiles;
std::vector <SDL_Surface*> tiles2;
std::vector <SDL_Surface*> tiles3;
std::vector <SDL_Surface*> entcolours;
std::vector <SDL_Surface*> sprites;
std::vector <SDL_Surface*> flipsprites;
std::vector <SDL_Surface*> bfont;
std::vector <SDL_Surface*> flipbfont;
bool flipmode;
bool setflipmode;
Add text outline as an accessibility option
2020-01-17 18:37:53 +01:00
bool notextoutline;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
//buffer objects. //TODO refactor buffer objects
SDL_Surface* backBuffer;
Screen* screenbuffer;
SDL_Surface* menubuffer;
fix uninitialized member vars everywhere also fix a spelling error of 'forground' in the graphics class buffer
2020-01-11 01:37:23 +01:00
SDL_Surface* foregroundBuffer;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
SDL_Surface* tempBuffer;
Move horizontal/vertical warp backgrounds to separate buffers Instead of using the same tower buffer that gets used for towers, use a separate buffer instead so there's no risk of stepping on the tower buffer's toes at the wrong point in time. This commit combined with the previous one fixes #369.
2020-11-03 01:54:17 +01:00
SDL_Surface* warpbuffer;
SDL_Surface* warpbuffer_lerp;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Refactor tower background to use a separate object instead Previously, the tower background was controlled by a disparate set of attributes on Graphics and mapclass, and wasn't really encapsulated. (If that's what that word means, I don't particularly care about object-oriented lingo.) But now, all relevant things that a tower background has has been put into a TowerBG struct, so it will be easy to make multiple copies without having to duplicate the code that handles it.
2020-11-03 00:05:24 +01:00
TowerBG towerbg;
Move title usages of towerbg to titlebg With the previous commit in place, we can now simply move some usages of the previous towerbg to use a separate object instead. That way, we don't have to mess with a monolithic state, or some better way to phrase what I just said, and we instead have two separate objects that can coexist side-by-side.
2020-11-03 00:23:53 +01:00
TowerBG titlebg;
Refactor tower background to use a separate object instead Previously, the tower background was controlled by a disparate set of attributes on Graphics and mapclass, and wasn't really encapsulated. (If that's what that word means, I don't particularly care about object-oriented lingo.) But now, all relevant things that a tower background has has been put into a TowerBG struct, so it will be easy to make multiple copies without having to duplicate the code that handles it.
2020-11-03 00:05:24 +01:00
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
SDL_Rect bfont_rect;
SDL_Rect tiles_rect;
SDL_Rect sprites_rect;
SDL_Rect images_rect;
SDL_Rect bg_rect;
SDL_Rect line_rect;
SDL_Rect tele_rect;
Add 8 pixels of padding above and left of towerbuffer[_lerp] In order to fix the weird title screen pixels at the top on deltaframes, we'll need to have a bit more space at the top. Also to the left, in case we need a background to scroll from the left in the future.
2020-11-02 19:44:53 +01:00
SDL_Rect towerbuffer_rect;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
SDL_Rect foot_rect;
SDL_Rect prect;
SDL_Rect footerrect;
Convert roomname background to a surface, then draw that The roomname background used to just be a simple SDL_Rect that was drawn using SDL_FillRect with a color of 0. Unfortunately, it seems that you cannot use transparent colors with SDL_FillRect, it just defaults to being fully opaque. However, you CAN draw surfaces with translucency, which seems like the easiest thing to do. But the first step is to convert the roomname background to an SDL_Surface. This replaces the FillRect()s with SDL_BlitSurface() in the three places roomnames are drawn: in towerrender, in gamerender, and in editorrender.
2020-01-25 05:32:55 +01:00
SDL_Surface* footerbuffer;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int linestate, linedelay;
int backoffset;
bool backgrounddrawn, foregrounddrawn;
int menuoffset;
Interpolate bringing up and down quit/pause/teleporter screen Now it's really, really smooth. Except for like the last frame when it goes down, which I sometimes didn't notice (but maybe it didn't happen every time due to being lucky on the delta timesteps or something, whatevs.)
2020-04-29 05:46:33 +02:00
int oldmenuoffset;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
bool resumegamemode;
SDL_Rect warprect;
int crewframe;
int crewframedelay;
int fademode;
int fadeamount;
Interpolate fade amount This makes the fadeouts and fadeins (screenwipes) much more buttery smooth.
2020-04-29 03:10:40 +02:00
int oldfadeamount;
Turn fadebars into an array There's always 15 of them, it doesn't need to be a vector.
2020-07-03 11:40:57 +02:00
int fadebars[15];
Set fademode to temp 0 when going to in-game options While I've decoupled fademode from gamemode starting, being faded out on the title screen results in a black screen and you being unable to make any input. So we'll need to store the current fademode in a temporary variable when going to in-game options, then put it back when we return to the pause menu. Yes, you can turn on glitchrunner mode during the in-game options, and then immediately return to the pause menu to instantly go back to the title screen; this is intended. Due to frame ordering, putting the fademode back needs to be deferred to the end of the frame to prevent a 1-frame flicker. It's actually sufficient enough to do this temporary fademode storage to fix the whole thing, but I also decided to decouple fademode and gamemode starting just to be sure.
2021-03-20 07:23:18 +01:00
int ingame_fademode;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
bool trinketcolset;
int trinketr, trinketg, trinketb;
std::vector <textboxclass> textbox;
bool showcutscenebars;
int cutscenebarspos;
Interpolate cutscene bars position Cutscene bars will now smoothly fade in and out at above 30 FPS instead of at 30 FPS only.
2020-04-29 02:16:24 +02:00
int oldcutscenebarspos;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn star and backbox vectors into arrays There's always 50 stars and always 18 backboxes, there's no reason to have them be vectors.
2020-07-03 11:31:13 +02:00
static const int numstars = 50;
SDL_Rect stars[numstars];
int starsspeed[numstars];
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Turn star and backbox vectors into arrays There's always 50 stars and always 18 backboxes, there's no reason to have them be vectors.
2020-07-03 11:31:13 +02:00
static const int numbackboxes = 18;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int spcol, spcoldel;
Turn star and backbox vectors into arrays There's always 50 stars and always 18 backboxes, there's no reason to have them be vectors.
2020-07-03 11:31:13 +02:00
SDL_Rect backboxes[numbackboxes];
int backboxvx[numbackboxes];
int backboxvy[numbackboxes];
float backboxint[numbackboxes];
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
int warpskip, warpfcol, warpbcol;
Add an accessibility option to be able to see through the roomname This is the variable dwgfx.translucentroomname and <translucentroomname> in unlock.vvv. This lets you see through the black background of the roomname at the bottom of the screen, i.e. it makes the roomname background translucent. So you can see if someone decides to hide pesky spikes there.
2020-01-25 05:43:04 +01:00
bool translucentroomname;
Add graphics option to toggle mouse cursor Adds an option to show or hide the system mouse cursor over the game window.
2020-01-29 08:17:13 +01:00
Add support for Unicode rendering (#47) This uses utfcpp combined with a custom font, in the form of a PNG and text file. By default, the game acts exactly as it did before; custom fonts can be provided by third parties.
2020-01-31 19:25:37 +01:00
std::map<int, int> font_positions;
Add a player trail to the editor (ghosts) A few months ago, I added ghosts to the VVVVVV: Community Edition editor. I was told recently I should think about upstreaming it, and with Terry saying go ahead I finally ported them into VVVVVV. There's one slight difference however--you can choose whether you have them or not in the editor's settings menu. They're off by default, and this is saved to the save file. Anyway, when you're playtesting, the game saves the players position, color, room coordinates and sprite every 3 frames. The max is 100, where if it tries to add more, the oldest one gets removed. When you exit playtesting, the saved positions appear one at a time, and you can use the Z key to speed it up. [Here's a video of them in action.](https://o.lol-sa.me/4H21zCv.mp4)
2020-06-13 00:04:35 +02:00
Fix mixed indentation The editors I use replace tabs with spaces, so I never really thought about mixed indentation happening. Whoops.
2020-06-13 00:20:39 +02:00
SDL_Surface* ghostbuffer;
Add linear interpolation of rendered entities I've added a function Graphics::lerp() which simply interpolates between two values given a certain alpha value. It's just like drawing a straight line between two points. Also, Graphics now has an `alpha` attribute, and it is set on every deltatime update to be used in linear interpolation.
2020-04-29 01:02:55 +02:00
float inline lerp(const float v0, const float v1)
{
return v0 + alpha * (v1 - v0);
}
float alpha;
Fix colors updating too fast in TITLEMODE/MAPMODE/GAMECOMPLETEMODE These colors were of the colors of each crewmate, the inactive crewmate color, and the color of the trinket and clock on the quicksave/summary screens. These colors all used fRandom() and so kept updating too quickly because they would be recalculated every time the delta-timestep render function got called, which isn't ideal. Thus, I've had to add attributes onto the Graphics class to store these colors and make sure they're only recalculated in logic functions instead. Thankfully, the color used for the sprites on the time trial results screen doesn't use fRandom(), so I don't have to worry about those. There's a new version of Graphics::drawsprite() that takes in a pre-made color already, instead of a color ID. As well, I've also added Graphics::updatetitlecolours() to update these colors on the title screen.
2020-05-02 01:40:35 +02:00
Uint32 col_crewred;
Uint32 col_crewyellow;
Uint32 col_crewgreen;
Uint32 col_crewcyan;
Uint32 col_crewblue;
Uint32 col_crewpurple; //actually pink
Uint32 col_crewinactive;
Uint32 col_clock;
Uint32 col_trinket;
int col_tr;
int col_tg;
int col_tb;
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 updatetitlecolours(void);
Fix off-by-one in interpolation of extending gravity line Currently it interpolates it based on the current state of game.swngame, but when game.swngame changes the interpolation doesn't know that it has JUST changed or anything. So add a kludge variable to fix this off-by-one.
2020-05-02 21:06:40 +02:00
bool kludgeswnlinewidth;
Make sure sprite colors in the editor don't update more than 30 FPS This adds Graphics::crewcolourreal(), which is like the entityclass::crewcolour() that the editor already uses, except for the real color instead of the color ID. Also, editorclass now has an attribute `entcolreal` so enemy colors don't update more than 30 frames a second.
2020-05-02 22:53:19 +02:00
Uint32 crewcolourreal(int t);
Do not close game if custom level has assets issues It's quite rude to close the game entirely if there is trouble with assets. Instead, just unload the assets and gracefully return to the title screen.
2021-08-07 05:57:34 +02:00
char error[128];
char error_title[128]; /* for SDL_ShowSimpleMessageBox */
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
};
Clean up and prevent unnecessary qualifiers to self By "unnecessary qualifiers to self", I mean something like using the 'game.' qualifier for a variable on the Game class when you're inside a function on the Game class itself. This patch is to enforce consistency as most of the code doesn't have these unnecessary qualifiers. To prevent further unnecessary qualifiers to self, I made it so the extern in each header file can be omitted by using a define. That way, if someone writes something referring to 'game.' on a Game function, there will be a compile error. However, if you really need to have a reference to the global name, and you're within the same .cpp file as the implementation of that object, you can just do the extern at the function-level. A good example of this is editorinput()/editorrender()/editorlogic() in editor.cpp. In my opinion, they should probably be split off into their own separate file because editor.cpp is getting way too big, but this will do for now.
2020-09-28 04:15:06 +02:00
#ifndef GRAPHICS_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 Graphics graphics;
Clean up and prevent unnecessary qualifiers to self By "unnecessary qualifiers to self", I mean something like using the 'game.' qualifier for a variable on the Game class when you're inside a function on the Game class itself. This patch is to enforce consistency as most of the code doesn't have these unnecessary qualifiers. To prevent further unnecessary qualifiers to self, I made it so the extern in each header file can be omitted by using a define. That way, if someone writes something referring to 'game.' on a Game function, there will be a compile error. However, if you really need to have a reference to the global name, and you're within the same .cpp file as the implementation of that object, you can just do the extern at the function-level. A good example of this is editorinput()/editorrender()/editorlogic() in editor.cpp. In my opinion, they should probably be split off into their own separate file because editor.cpp is getting way too big, but this will do for now.
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
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#endif /* GRAPHICS_H */
Reference in a new issue Copy permalink