2020-09-28 04:15:06 +02:00
|
|
|
#define GRAPHICS_DEFINITION
|
2020-01-01 21:29:24 +01:00
|
|
|
#include "Graphics.h"
|
2020-07-19 21:43:29 +02:00
|
|
|
|
2021-11-12 08:52:47 +01:00
|
|
|
#include <SDL.h>
|
2020-07-19 21:43:29 +02:00
|
|
|
|
2022-12-01 07:30:16 +01:00
|
|
|
#include "Alloc.h"
|
2021-09-25 01:37:27 +02:00
|
|
|
#include "Constants.h"
|
2021-02-20 08:19:09 +01:00
|
|
|
#include "CustomLevels.h"
|
2020-01-01 21:29:24 +01:00
|
|
|
#include "Entity.h"
|
2021-02-16 03:53:17 +01:00
|
|
|
#include "Exit.h"
|
2020-07-19 21:43:29 +02:00
|
|
|
#include "FileSystemUtils.h"
|
Start rewrite of font system
This is still a work in progress, but the existing font system has been
removed and replaced by a new one, in Font.cpp.
Design goals of the new font system include supporting colored button
glyphs, different fonts for different languages, and larger fonts than
8x8 for Chinese, Japanese and Korean, while being able to support their
30000+ characters without hiccups, slowdowns or high memory usage. And
to have more flexibility with fonts in general. Plus, Graphics.cpp was
long enough as-is, so it's good to have a dedicated file for font
storage.
The old font system worked with a std::vector<SDL_Surface*> to store
8x8 surfaces for each character, and a std::map<int,int> to store
mappings between codepoints and vector indexes.
The new system has a per-font collection of pages for every block of
0x1000 (4096) codepoints, that may be allocated as needed. A glyph on
a page contains the index of the glyph in the image (giving its
coordinates), the advance (how much the cursor should advance, so the
width of that glyph) and some flags which would be at least whether the
glyph exists and whether it is colored.
Most of the *new* features aren't implemented yet; it's currently
hardcoded to the regular 8x8 font.png, but it should be functionally
equivalent to the previous behavior. The only thing that doesn't really
work yet is level-specific font.png, but that'll be supported again
soon enough.
This commit also adds fontmeta (xml) support.
Since the fonts folder is mounted at graphics/, there are two main
options for recognizing non-font.png fonts: the font files have to be
prefixed with font (or font_) or some special file extension is
involved to signal what files are fonts. I always had a font.xml in
mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be
a need for further xml files inside the graphics folder, we have a
problem. So I named them .fontmeta instead.
A .fontmeta file looks somewhat like this:
<?xml version="1.0" encoding="UTF-8"?>
<font_metadata>
<width>12</width>
<height>12</height>
<white_teeth>1</white_teeth>
<chars>
<range start="0x20" end="0x7E"/>
<range start="0x80" end="0x80"/>
<range start="0xA0" end="0xDF"/>
<range start="0x250" end="0x2A8"/>
<range start="0x2AD" end="0x2AD"/>
<range start="0x2C7" end="0x2C7"/>
<range start="0x2C9" end="0x2CB"/>
...
</chars>
<special>
<range start="0x00" end="0x1F" advance="6"/>
<range start="0x61" end="0x66" color="1"/>
<range start="0x63" end="0x63" color="0"/>
</special>
</font_metadata>
The <chars> tag can be used to specify characters instead of in a .txt.
The original idea was to just always use the existing .txt system for
specifying the font charset, and only use the XML for the other stuff
that the .txt doesn't cover. However, it's probably better to keep it
simple if possible - having to only have a .png and a .fontmeta seems
simpler than having the data spread out over three files. And a major
advantage: Chinese fonts can have about 30000 characters! It's more
efficient to be able to have a tag saying "now there's 20902 characters
starting at U+4E00" than to include them all in a text file and having
to UTF-8 decode every single one of them.
If a font.txt exists, it takes priority over the <chars> tag, and in
that case, there's no reason to include the <chars> tag in the XML.
But font.txt has to be in the same directory as font.png, otherwise it
is rejected. Same for font.fontmeta. If neither font.txt nor <chars>
exist, then the font is seen as a 2.2-and-below-style ASCII font.
In <special>: advance is the number of pixels the cursor advances after
drawing the character (so the width of the character, without affecting
the grid in the source image), color is whether the character should
have its original colors retained when printed (for button glyphs).
As for <white_teeth>:
The renderer PR has replaced draw-time whitening of sprites/etc
(using BlitSurfaceColoured) by load-time whitening of entire images
(using LoadImage with TEX_WHITE as an argument).
This means we have a problem: fonts have always had their glyphs
whitened at printing time, and since I'm adding support for colored
button glyphs, I changed it so glyphs would sometimes not be whitened.
But if we can't whiten at print time, then we'd need to whiten at load
time, and if we whiten the entire font, any colored glyphs will get
destroyed too. If you whiten the image selectively, well, we need more
code to target specific squares in the image, and it's kind of a waste
when you need to whiten 30000 12x12 Chinese characters when you're only
going to need a handful, but you don't know which ones.
The solution: Whitening fonts is useless if all the non-colored glyphs
are already white, so we don't need to do it anyway! However, any
existing fonts that have non-white glyphs (and I know of at least one
level like that) will still need to be whitened. So there is now a
font property <white_teeth> that can be specified in the fontmeta,
which indicates that the font is already pre-whitened. If not
specified, traditional whitening behavior will be used, and the font
cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
|
|
|
#include "Font.h"
|
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
|
|
|
#include "GraphicsUtil.h"
|
2022-12-30 22:57:24 +01:00
|
|
|
#include "Localization.h"
|
2020-01-01 21:29:24 +01:00
|
|
|
#include "Map.h"
|
2023-01-29 08:32:14 +01:00
|
|
|
#include "Maths.h"
|
2020-07-19 21:05:41 +02:00
|
|
|
#include "Music.h"
|
2022-12-30 22:57:24 +01:00
|
|
|
#include "RoomnameTranslator.h"
|
2020-01-01 21:29:24 +01:00
|
|
|
#include "Screen.h"
|
2020-07-19 21:05:41 +02:00
|
|
|
#include "UtilityClass.h"
|
2022-12-30 22:57:24 +01:00
|
|
|
#include "VFormat.h"
|
2021-02-24 00:21:29 +01:00
|
|
|
#include "Vlogging.h"
|
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 Graphics::init(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
flipmode = false;
|
|
|
|
setRect(tiles_rect, 0,0,8,8);
|
|
|
|
setRect(sprites_rect, 0,0,32,32);
|
|
|
|
setRect(footerrect, 0, 230, 320, 10);
|
|
|
|
setRect(prect, 0, 0, 4, 4);
|
|
|
|
setRect(line_rect, 0,0,0,0);
|
|
|
|
setRect(tele_rect,0,0,96,96);
|
|
|
|
|
|
|
|
|
|
|
|
//We initialise a few things
|
|
|
|
|
2020-04-02 22:05:48 +02:00
|
|
|
linestate = 0;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
trinketcolset = false;
|
|
|
|
|
|
|
|
showcutscenebars = false;
|
2021-03-20 07:08:35 +01:00
|
|
|
setbars(0);
|
2020-01-17 18:37:53 +01:00
|
|
|
notextoutline = false;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
flipmode = false;
|
|
|
|
setflipmode = false;
|
|
|
|
|
|
|
|
//Background inits
|
2020-07-03 11:31:13 +02:00
|
|
|
for (int i = 0; i < numstars; i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
Remove unnecessary Sint16 casts
These casts are sprinkled all throughout the graphics code when creating
and initializing an SDL_Rect on the same line. Unfortunately, most of
these are unnecessary, and at worst are wasteful because they result in
narrowing a 4-byte integer into a 2-byte one when they don't need to
(SDL_Rects are made up of 4-byte integers).
Now, removing them reveals why they were placed there in the first place
- a warning is raised (-Wnarrowing) that implicit narrowing conversions
are prohibited in initializer lists in C++11. (Notably, if the
conversion wasn't narrowing, or implicit, or done in an initializer
list, it would be fine. This is a really specific prohibition that
doesn't apply if any of its sub-cases are true.)
We don't use C++11, but this warning can be easily vanquished by a
simple explicit cast to int (similar to the error of implicitly
converting void* to any other pointer in C++, which works just fine in
C), and we only need to do it when the warning is raised (not every
single time we make an SDL_Rect), so there we go.
2021-04-18 20:13:12 +02:00
|
|
|
SDL_Rect s = {(int) (fRandom() * 320), (int) (fRandom() * 240), 2, 2};
|
2020-01-01 21:29:24 +01:00
|
|
|
int s2 = 4+(fRandom()*4);
|
2020-07-03 11:31:13 +02:00
|
|
|
stars[i] = s;
|
|
|
|
starsspeed[i] = s2;
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-07-03 11:31:13 +02:00
|
|
|
for (int i = 0; i < numbackboxes; i++)
|
|
|
|
{
|
2020-01-01 21:29:24 +01:00
|
|
|
SDL_Rect bb;
|
|
|
|
int bvx = 0;
|
|
|
|
int bvy = 0;
|
|
|
|
if(fRandom()*100 > 50)
|
|
|
|
{
|
|
|
|
bvx = 9 - (fRandom() * 19);
|
|
|
|
if (bvx > -6 && bvx < 6) bvx = 6;
|
|
|
|
bvx = bvx * 1.5;
|
|
|
|
setRect(bb, fRandom() * 320, fRandom() * 240, 32, 12);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
bvy = 9 - (fRandom() * 19);
|
|
|
|
if (bvy > -6 && bvy < 6) bvy = 6;
|
|
|
|
bvy = bvy * 1.5;
|
|
|
|
setRect(bb, fRandom() * 320, fRandom() * 240, 12, 32) ;
|
|
|
|
}
|
|
|
|
float bint = 0.5 + ((fRandom() * 100) / 200);
|
2020-07-03 11:31:13 +02:00
|
|
|
backboxes[i] = bb;
|
|
|
|
backboxvx[i] = bvx;
|
|
|
|
backboxvy[i] = bvy;
|
|
|
|
backboxint[i] = bint;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
backoffset = 0;
|
2023-01-07 19:28:07 +01:00
|
|
|
foregrounddrawn = false;
|
2020-01-01 21:29:24 +01:00
|
|
|
backgrounddrawn = false;
|
|
|
|
|
|
|
|
warpskip = 0;
|
|
|
|
|
|
|
|
spcol = 0;
|
|
|
|
spcoldel = 0;
|
2020-04-02 22:05:48 +02:00
|
|
|
rcol = 0;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
crewframe = 0;
|
|
|
|
crewframedelay = 4;
|
|
|
|
menuoffset = 0;
|
2020-04-29 05:46:33 +02:00
|
|
|
oldmenuoffset = 0;
|
2020-01-01 21:29:24 +01:00
|
|
|
resumegamemode = false;
|
|
|
|
|
|
|
|
//Fading stuff
|
2020-07-03 11:40:57 +02:00
|
|
|
SDL_memset(fadebars, 0, sizeof(fadebars));
|
2020-01-12 18:26:00 +01:00
|
|
|
|
2021-03-20 07:09:11 +01:00
|
|
|
setfade(0);
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
fademode = FADE_NONE;
|
|
|
|
ingame_fademode = FADE_NONE;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-01-11 01:37:23 +01:00
|
|
|
// initialize everything else to zero
|
|
|
|
m = 0;
|
|
|
|
linedelay = 0;
|
2023-01-07 19:28:07 +01:00
|
|
|
gameTexture = NULL;
|
|
|
|
gameplayTexture = NULL;
|
|
|
|
menuTexture = NULL;
|
|
|
|
ghostTexture = NULL;
|
2023-03-04 00:25:15 +01:00
|
|
|
menuoffTexture = NULL;
|
2023-01-07 19:28:07 +01:00
|
|
|
backgroundTexture = NULL;
|
|
|
|
foregroundTexture = NULL;
|
2020-11-03 00:05:24 +01:00
|
|
|
towerbg = TowerBG();
|
2020-11-03 00:23:53 +01:00
|
|
|
titlebg = TowerBG();
|
2020-01-11 01:37:23 +01:00
|
|
|
trinketr = 0;
|
|
|
|
trinketg = 0;
|
|
|
|
trinketb = 0;
|
2020-01-25 05:43:04 +01:00
|
|
|
|
|
|
|
translucentroomname = false;
|
2020-04-29 01:02:55 +02:00
|
|
|
|
|
|
|
alpha = 1.0f;
|
2020-04-29 02:29:59 +02:00
|
|
|
|
|
|
|
screenshake_x = 0;
|
|
|
|
screenshake_y = 0;
|
2020-05-02 01:40:35 +02:00
|
|
|
|
2023-01-02 01:36:43 +01:00
|
|
|
SDL_zero(col_crewred);
|
|
|
|
SDL_zero(col_crewyellow);
|
|
|
|
SDL_zero(col_crewgreen);
|
|
|
|
SDL_zero(col_crewcyan);
|
|
|
|
SDL_zero(col_crewblue);
|
|
|
|
SDL_zero(col_crewpurple);
|
|
|
|
SDL_zero(col_crewinactive);
|
|
|
|
SDL_zero(col_clock);
|
|
|
|
SDL_zero(col_trinket);
|
2020-05-02 01:40:35 +02:00
|
|
|
col_tr = 0;
|
|
|
|
col_tg = 0;
|
|
|
|
col_tb = 0;
|
2020-05-02 21:06:40 +02:00
|
|
|
|
|
|
|
kludgeswnlinewidth = false;
|
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
|
|
|
|
tiles1_mounted = false;
|
|
|
|
tiles2_mounted = false;
|
2021-04-19 08:39:10 +02:00
|
|
|
minimap_mounted = false;
|
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
|
2021-08-07 05:57:34 +02:00
|
|
|
|
2022-12-30 22:57:24 +01:00
|
|
|
gamecomplete_mounted = false;
|
|
|
|
levelcomplete_mounted = false;
|
|
|
|
flipgamecomplete_mounted = false;
|
|
|
|
fliplevelcomplete_mounted = false;
|
|
|
|
|
2021-08-07 05:57:34 +02:00
|
|
|
SDL_zeroa(error);
|
|
|
|
SDL_zeroa(error_title);
|
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 Graphics::destroy(void)
|
2021-02-16 01:13:18 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
#define CLEAR_ARRAY(name) \
|
|
|
|
for (size_t i = 0; i < name.size(); i += 1) \
|
|
|
|
{ \
|
|
|
|
VVV_freefunc(SDL_FreeSurface, name[i]); \
|
|
|
|
} \
|
|
|
|
name.clear();
|
|
|
|
|
|
|
|
CLEAR_ARRAY(sprites_surf)
|
|
|
|
CLEAR_ARRAY(flipsprites_surf)
|
|
|
|
|
|
|
|
#undef CLEAR_ARRAY
|
|
|
|
}
|
|
|
|
|
2023-03-04 23:02:47 +01:00
|
|
|
static SDL_Surface* tempFilterSrc = NULL;
|
|
|
|
static SDL_Surface* tempFilterDest = NULL;
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
void Graphics::create_buffers(void)
|
|
|
|
{
|
|
|
|
#define CREATE_TEXTURE_WITH_DIMENSIONS(w, h) \
|
|
|
|
SDL_CreateTexture( \
|
|
|
|
gameScreen.m_renderer, \
|
|
|
|
SDL_PIXELFORMAT_ARGB8888, SDL_TEXTUREACCESS_TARGET, \
|
|
|
|
(w), (h) \
|
|
|
|
)
|
|
|
|
#define CREATE_TEXTURE \
|
|
|
|
CREATE_TEXTURE_WITH_DIMENSIONS(SCREEN_WIDTH_PIXELS, SCREEN_HEIGHT_PIXELS)
|
|
|
|
#define CREATE_SCROLL_TEXTURE \
|
|
|
|
CREATE_TEXTURE_WITH_DIMENSIONS(SCREEN_WIDTH_PIXELS + 16, SCREEN_WIDTH_PIXELS + 16)
|
|
|
|
|
|
|
|
gameTexture = CREATE_TEXTURE;
|
|
|
|
gameplayTexture = CREATE_TEXTURE;
|
|
|
|
menuTexture = CREATE_TEXTURE;
|
|
|
|
ghostTexture = CREATE_TEXTURE;
|
2023-03-04 00:25:15 +01:00
|
|
|
menuoffTexture = CREATE_TEXTURE;
|
2023-01-07 19:28:07 +01:00
|
|
|
foregroundTexture = CREATE_TEXTURE;
|
|
|
|
backgroundTexture = CREATE_SCROLL_TEXTURE;
|
2023-03-04 01:02:53 +01:00
|
|
|
tempScrollingTexture = CREATE_SCROLL_TEXTURE;
|
2023-01-07 19:28:07 +01:00
|
|
|
towerbg.texture = CREATE_SCROLL_TEXTURE;
|
|
|
|
titlebg.texture = CREATE_SCROLL_TEXTURE;
|
2023-03-04 00:23:55 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
#undef CREATE_SCROLL_TEXTURE
|
|
|
|
#undef CREATE_TEXTURE
|
|
|
|
#undef CREATE_TEXTURE_WITH_DIMENSIONS
|
2021-02-16 01:18:45 +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 Graphics::destroy_buffers(void)
|
2021-02-16 01:16:52 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
VVV_freefunc(SDL_DestroyTexture, gameTexture);
|
|
|
|
VVV_freefunc(SDL_DestroyTexture, gameplayTexture);
|
|
|
|
VVV_freefunc(SDL_DestroyTexture, menuTexture);
|
|
|
|
VVV_freefunc(SDL_DestroyTexture, ghostTexture);
|
2023-03-04 00:25:15 +01:00
|
|
|
VVV_freefunc(SDL_DestroyTexture, menuoffTexture);
|
2023-01-07 19:28:07 +01:00
|
|
|
VVV_freefunc(SDL_DestroyTexture, foregroundTexture);
|
|
|
|
VVV_freefunc(SDL_DestroyTexture, backgroundTexture);
|
2023-03-04 01:02:53 +01:00
|
|
|
VVV_freefunc(SDL_DestroyTexture, tempScrollingTexture);
|
2023-03-04 00:34:13 +01:00
|
|
|
VVV_freefunc(SDL_DestroyTexture, towerbg.texture);
|
|
|
|
VVV_freefunc(SDL_DestroyTexture, titlebg.texture);
|
2023-03-04 23:02:47 +01:00
|
|
|
VVV_freefunc(SDL_FreeSurface, tempFilterSrc);
|
|
|
|
VVV_freefunc(SDL_FreeSurface, tempFilterDest);
|
2021-02-16 01:16:52 +01:00
|
|
|
}
|
|
|
|
|
2020-03-31 21:26:11 +02:00
|
|
|
void Graphics::drawspritesetcol(int x, int y, int t, int c)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_sprites, t, x, y, sprites_rect.w, sprites_rect.h, getcol(c));
|
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 Graphics::updatetitlecolours(void)
|
2020-05-02 01:40:35 +02:00
|
|
|
{
|
2023-01-02 05:16:08 +01:00
|
|
|
col_crewred = getcol(15);
|
|
|
|
col_crewyellow = getcol(14);
|
|
|
|
col_crewgreen = getcol(13);
|
|
|
|
col_crewcyan = getcol(0);
|
|
|
|
col_crewblue = getcol(16);
|
|
|
|
col_crewpurple = getcol(20);
|
|
|
|
col_crewinactive = getcol(19);
|
|
|
|
|
|
|
|
col_clock = getcol(18);
|
|
|
|
col_trinket = getcol(18);
|
2020-05-02 01:40:35 +02:00
|
|
|
}
|
|
|
|
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
#define PROCESS_TILESHEET_CHECK_ERROR(tilesheet, tile_square) \
|
2021-04-18 19:57:48 +02:00
|
|
|
if (grphx.im_##tilesheet == NULL) \
|
|
|
|
{ \
|
|
|
|
/* We have already asserted; just no-op. */ \
|
|
|
|
} \
|
|
|
|
else if (grphx.im_##tilesheet->w % tile_square != 0 \
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
|| grphx.im_##tilesheet->h % tile_square != 0) \
|
|
|
|
{ \
|
2021-08-07 05:57:34 +02:00
|
|
|
static const char error_fmt[] = "%s.png dimensions not exact multiples of %i!"; \
|
|
|
|
static const char error_title_fmt[] = "Error with %s.png"; \
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
\
|
2021-08-07 05:57:34 +02:00
|
|
|
SDL_snprintf(error, sizeof(error), error_fmt, #tilesheet, tile_square); \
|
|
|
|
SDL_snprintf(error_title, sizeof(error_title), error_title_fmt, #tilesheet); \
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
\
|
2021-12-05 15:50:20 +01:00
|
|
|
vlog_error("%s", error); \
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
\
|
2021-08-07 05:57:34 +02:00
|
|
|
return false; \
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
#define PROCESS_TILESHEET_RENAME(tilesheet, vector, tile_square, extra_code) \
|
|
|
|
PROCESS_TILESHEET_CHECK_ERROR(tilesheet, tile_square) \
|
|
|
|
\
|
2021-04-18 19:57:48 +02:00
|
|
|
else \
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
{ \
|
2021-04-18 19:57:48 +02:00
|
|
|
int j; \
|
|
|
|
for (j = 0; j < grphx.im_##tilesheet->h / tile_square; ++j) \
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
{ \
|
2021-04-18 19:57:48 +02:00
|
|
|
int i; \
|
|
|
|
for (i = 0; i < grphx.im_##tilesheet->w / tile_square; ++i) \
|
|
|
|
{ \
|
|
|
|
SDL_Surface* temp = GetSubSurface( \
|
|
|
|
grphx.im_##tilesheet, \
|
|
|
|
i * tile_square, j * tile_square, \
|
|
|
|
tile_square, tile_square \
|
|
|
|
); \
|
|
|
|
vector.push_back(temp); \
|
|
|
|
\
|
|
|
|
extra_code \
|
|
|
|
} \
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
} \
|
2021-04-18 19:57:48 +02:00
|
|
|
\
|
2022-12-01 07:30:16 +01:00
|
|
|
VVV_freefunc(SDL_FreeSurface, grphx.im_##tilesheet); \
|
2021-04-18 19:57:48 +02:00
|
|
|
}
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
|
|
|
|
#define PROCESS_TILESHEET(tilesheet, tile_square, extra_code) \
|
|
|
|
PROCESS_TILESHEET_RENAME(tilesheet, tilesheet, tile_square, extra_code)
|
|
|
|
|
2021-08-07 05:57:34 +02:00
|
|
|
bool Graphics::MakeSpriteArray(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
PROCESS_TILESHEET(sprites_surf, 32, {})
|
|
|
|
PROCESS_TILESHEET(flipsprites_surf, 32, {})
|
2021-08-07 05:57:34 +02:00
|
|
|
|
|
|
|
return true;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
Refactor, de-duplicate, and clean up tilesheet processing
The tilesheets in question are font.png, tiles.png, tiles2.png,
tiles3.png, entcolours.png, teleporter.png, sprites.png, and
flipsprites.png.
This patch removes the hardcoded dimensions when scanning the
tilesheets, because it's simpler that way. It also de-duplicates it so
it isn't a bunch of copy-paste, by using macros. (I had to use macros
because it was the easiest way to optionally pass in some extra code in
the innermost for-loop.)
Also, if the dimensions of a scanned tilesheet aren't exactly multiples
of the dimensions of the tile unit for that given tilesheet (e.g. if the
dimensions of a scanned tiles.png are not exact multiples of 8), then an
SDL_SimpleMessageBox will show up with the error message, a puts() of
the error message will be called, and the program will exit.
2020-06-28 08:59:47 +02:00
|
|
|
#undef PROCESS_TILESHEET
|
|
|
|
#undef PROCESS_TILESHEET_RENAME
|
|
|
|
#undef PROCESS_TILESHEET_CHECK_ERROR
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2022-12-31 01:48:27 +01:00
|
|
|
void Graphics::map_tab(int opt, const char* text, bool selected /*= false*/)
|
2020-06-21 03:33:55 +02:00
|
|
|
{
|
2022-12-31 01:48:27 +01:00
|
|
|
int x = opt*80 + 40;
|
2020-06-21 03:33:55 +02:00
|
|
|
if (selected)
|
|
|
|
{
|
2022-12-31 01:48:27 +01:00
|
|
|
char buffer[SCREEN_WIDTH_CHARS + 1];
|
|
|
|
vformat_buf(buffer, sizeof(buffer), loc::get_langmeta()->menu_select_tight.c_str(), "label:str", text);
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(PR_CEN | PR_CJK_LOW, x, 220, buffer, 196, 196, 255 - help.glow);
|
2020-06-21 03:33:55 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(PR_CEN | PR_CJK_LOW, x, 220, text, 64, 64, 64);
|
2020-06-21 03:33:55 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-06-23 00:23:15 +02:00
|
|
|
void Graphics::map_option(int opt, int num_opts, const std::string& text, bool selected /*= false*/)
|
|
|
|
{
|
|
|
|
int x = 80 + opt*32;
|
|
|
|
int y = 136; // start from middle of menu
|
|
|
|
|
|
|
|
int yoff = -(num_opts * 12) / 2; // could be simplified to -num_opts * 6, this conveys my intent better though
|
|
|
|
yoff += opt * 12;
|
|
|
|
|
|
|
|
if (flipmode)
|
|
|
|
{
|
|
|
|
y -= yoff; // going down, which in Flip Mode means going up
|
|
|
|
y -= 40;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
y += yoff; // going up
|
|
|
|
}
|
|
|
|
|
|
|
|
if (selected)
|
|
|
|
{
|
2022-12-30 23:39:12 +01:00
|
|
|
std::string text_upper(loc::toupper(text));
|
|
|
|
|
|
|
|
char buffer[SCREEN_WIDTH_CHARS + 1];
|
|
|
|
vformat_buf(buffer, sizeof(buffer), loc::get_langmeta()->menu_select.c_str(), "label:str", text_upper.c_str());
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x - 16, y, buffer, 196, 196, 255 - help.glow);
|
2020-06-23 00:23:15 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::remove_toupper_escape_chars(text), 96, 96, 96);
|
2020-06-23 00:23:15 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
void Graphics::printcrewname( int x, int y, int t )
|
|
|
|
{
|
|
|
|
//Print the name of crew member t in the right colour
|
|
|
|
switch(t)
|
|
|
|
{
|
|
|
|
case 0:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Viridian"), 16, 240, 240);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 1:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Violet"), 240, 16, 240);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 2:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Vitellary"), 240, 240, 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 3:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Vermilion"), 240, 16, 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 4:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Verdigris"), 16, 240, 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 5:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Victoria"), 16, 16, 240);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::printcrewnamedark( int x, int y, int t )
|
|
|
|
{
|
|
|
|
//Print the name of crew member t as above, but in black and white
|
|
|
|
switch(t)
|
|
|
|
{
|
|
|
|
case 0:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Viridian"), 128,128,128);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 1:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Violet"), 128,128,128);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 2:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Vitellary"), 128,128,128);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 3:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Vermilion"), 128,128,128);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 4:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Verdigris"), 128,128,128);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 5:
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, loc::gettext("Victoria"), 128,128,128);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add support for string cases in strings.xml (gendered Rescued/Missing)
I wanted to not complicate the system with different string cases (like
cgettext) if possible, and I have been able to keep the main strings a
simple English=Translation mapping thus far, but apparently strings
like "Rescued!" (which are one string in English), have to be
translated for the correct gender in some languages. So this was a good
time to add support for string cases anyway.
It's a number that can be given to a string to specify the specific
case it's used, to disambiguate identical English keys. In the case of
"Rescued!" and "Missing...", male versions of the string are case 1,
female versions are case 2, and Viridian being missing is case 3. Of
course, if a language doesn't need to use different variants, it can
simply fill in the same string for the different cases.
If any other string needs to switch to different cases: distinguish
them in the English strings.xml with the case="N" attribute (N=1 and
higher), sync language files from the translator menu (existing
translations for the uncased string will simply be copied to all cases)
and change loc::gettext("...") to loc::gettext_case("...", 1),
loc::gettext_case("...", 2), etc.
2022-12-01 01:27:30 +01:00
|
|
|
void Graphics::printcrewnamestatus( int x, int y, int t, bool rescued )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
//Print the status of crew member t in the right colour
|
Add support for string cases in strings.xml (gendered Rescued/Missing)
I wanted to not complicate the system with different string cases (like
cgettext) if possible, and I have been able to keep the main strings a
simple English=Translation mapping thus far, but apparently strings
like "Rescued!" (which are one string in English), have to be
translated for the correct gender in some languages. So this was a good
time to add support for string cases anyway.
It's a number that can be given to a string to specify the specific
case it's used, to disambiguate identical English keys. In the case of
"Rescued!" and "Missing...", male versions of the string are case 1,
female versions are case 2, and Viridian being missing is case 3. Of
course, if a language doesn't need to use different variants, it can
simply fill in the same string for the different cases.
If any other string needs to switch to different cases: distinguish
them in the English strings.xml with the case="N" attribute (N=1 and
higher), sync language files from the translator menu (existing
translations for the uncased string will simply be copied to all cases)
and change loc::gettext("...") to loc::gettext_case("...", 1),
loc::gettext_case("...", 2), etc.
2022-12-01 01:27:30 +01:00
|
|
|
int r, g, b;
|
|
|
|
char gender;
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
switch(t)
|
|
|
|
{
|
|
|
|
case 0:
|
Add support for string cases in strings.xml (gendered Rescued/Missing)
I wanted to not complicate the system with different string cases (like
cgettext) if possible, and I have been able to keep the main strings a
simple English=Translation mapping thus far, but apparently strings
like "Rescued!" (which are one string in English), have to be
translated for the correct gender in some languages. So this was a good
time to add support for string cases anyway.
It's a number that can be given to a string to specify the specific
case it's used, to disambiguate identical English keys. In the case of
"Rescued!" and "Missing...", male versions of the string are case 1,
female versions are case 2, and Viridian being missing is case 3. Of
course, if a language doesn't need to use different variants, it can
simply fill in the same string for the different cases.
If any other string needs to switch to different cases: distinguish
them in the English strings.xml with the case="N" attribute (N=1 and
higher), sync language files from the translator menu (existing
translations for the uncased string will simply be copied to all cases)
and change loc::gettext("...") to loc::gettext_case("...", 1),
loc::gettext_case("...", 2), etc.
2022-12-01 01:27:30 +01:00
|
|
|
r=12; g=140, b=140;
|
|
|
|
gender = 3;
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 1:
|
Add support for string cases in strings.xml (gendered Rescued/Missing)
I wanted to not complicate the system with different string cases (like
cgettext) if possible, and I have been able to keep the main strings a
simple English=Translation mapping thus far, but apparently strings
like "Rescued!" (which are one string in English), have to be
translated for the correct gender in some languages. So this was a good
time to add support for string cases anyway.
It's a number that can be given to a string to specify the specific
case it's used, to disambiguate identical English keys. In the case of
"Rescued!" and "Missing...", male versions of the string are case 1,
female versions are case 2, and Viridian being missing is case 3. Of
course, if a language doesn't need to use different variants, it can
simply fill in the same string for the different cases.
If any other string needs to switch to different cases: distinguish
them in the English strings.xml with the case="N" attribute (N=1 and
higher), sync language files from the translator menu (existing
translations for the uncased string will simply be copied to all cases)
and change loc::gettext("...") to loc::gettext_case("...", 1),
loc::gettext_case("...", 2), etc.
2022-12-01 01:27:30 +01:00
|
|
|
r=140; g=12; b=140;
|
|
|
|
gender = 2;
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 2:
|
Add support for string cases in strings.xml (gendered Rescued/Missing)
I wanted to not complicate the system with different string cases (like
cgettext) if possible, and I have been able to keep the main strings a
simple English=Translation mapping thus far, but apparently strings
like "Rescued!" (which are one string in English), have to be
translated for the correct gender in some languages. So this was a good
time to add support for string cases anyway.
It's a number that can be given to a string to specify the specific
case it's used, to disambiguate identical English keys. In the case of
"Rescued!" and "Missing...", male versions of the string are case 1,
female versions are case 2, and Viridian being missing is case 3. Of
course, if a language doesn't need to use different variants, it can
simply fill in the same string for the different cases.
If any other string needs to switch to different cases: distinguish
them in the English strings.xml with the case="N" attribute (N=1 and
higher), sync language files from the translator menu (existing
translations for the uncased string will simply be copied to all cases)
and change loc::gettext("...") to loc::gettext_case("...", 1),
loc::gettext_case("...", 2), etc.
2022-12-01 01:27:30 +01:00
|
|
|
r=140; g=140; b=12;
|
|
|
|
gender = 1;
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 3:
|
Add support for string cases in strings.xml (gendered Rescued/Missing)
I wanted to not complicate the system with different string cases (like
cgettext) if possible, and I have been able to keep the main strings a
simple English=Translation mapping thus far, but apparently strings
like "Rescued!" (which are one string in English), have to be
translated for the correct gender in some languages. So this was a good
time to add support for string cases anyway.
It's a number that can be given to a string to specify the specific
case it's used, to disambiguate identical English keys. In the case of
"Rescued!" and "Missing...", male versions of the string are case 1,
female versions are case 2, and Viridian being missing is case 3. Of
course, if a language doesn't need to use different variants, it can
simply fill in the same string for the different cases.
If any other string needs to switch to different cases: distinguish
them in the English strings.xml with the case="N" attribute (N=1 and
higher), sync language files from the translator menu (existing
translations for the uncased string will simply be copied to all cases)
and change loc::gettext("...") to loc::gettext_case("...", 1),
loc::gettext_case("...", 2), etc.
2022-12-01 01:27:30 +01:00
|
|
|
r=140; g=12; b=12;
|
|
|
|
gender = 1;
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 4:
|
Add support for string cases in strings.xml (gendered Rescued/Missing)
I wanted to not complicate the system with different string cases (like
cgettext) if possible, and I have been able to keep the main strings a
simple English=Translation mapping thus far, but apparently strings
like "Rescued!" (which are one string in English), have to be
translated for the correct gender in some languages. So this was a good
time to add support for string cases anyway.
It's a number that can be given to a string to specify the specific
case it's used, to disambiguate identical English keys. In the case of
"Rescued!" and "Missing...", male versions of the string are case 1,
female versions are case 2, and Viridian being missing is case 3. Of
course, if a language doesn't need to use different variants, it can
simply fill in the same string for the different cases.
If any other string needs to switch to different cases: distinguish
them in the English strings.xml with the case="N" attribute (N=1 and
higher), sync language files from the translator menu (existing
translations for the uncased string will simply be copied to all cases)
and change loc::gettext("...") to loc::gettext_case("...", 1),
loc::gettext_case("...", 2), etc.
2022-12-01 01:27:30 +01:00
|
|
|
r=12; g=140; b=12;
|
|
|
|
gender = 1;
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 5:
|
Add support for string cases in strings.xml (gendered Rescued/Missing)
I wanted to not complicate the system with different string cases (like
cgettext) if possible, and I have been able to keep the main strings a
simple English=Translation mapping thus far, but apparently strings
like "Rescued!" (which are one string in English), have to be
translated for the correct gender in some languages. So this was a good
time to add support for string cases anyway.
It's a number that can be given to a string to specify the specific
case it's used, to disambiguate identical English keys. In the case of
"Rescued!" and "Missing...", male versions of the string are case 1,
female versions are case 2, and Viridian being missing is case 3. Of
course, if a language doesn't need to use different variants, it can
simply fill in the same string for the different cases.
If any other string needs to switch to different cases: distinguish
them in the English strings.xml with the case="N" attribute (N=1 and
higher), sync language files from the translator menu (existing
translations for the uncased string will simply be copied to all cases)
and change loc::gettext("...") to loc::gettext_case("...", 1),
loc::gettext_case("...", 2), etc.
2022-12-01 01:27:30 +01:00
|
|
|
r=12; g=12; b=140;
|
|
|
|
gender = 2;
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
Add support for string cases in strings.xml (gendered Rescued/Missing)
I wanted to not complicate the system with different string cases (like
cgettext) if possible, and I have been able to keep the main strings a
simple English=Translation mapping thus far, but apparently strings
like "Rescued!" (which are one string in English), have to be
translated for the correct gender in some languages. So this was a good
time to add support for string cases anyway.
It's a number that can be given to a string to specify the specific
case it's used, to disambiguate identical English keys. In the case of
"Rescued!" and "Missing...", male versions of the string are case 1,
female versions are case 2, and Viridian being missing is case 3. Of
course, if a language doesn't need to use different variants, it can
simply fill in the same string for the different cases.
If any other string needs to switch to different cases: distinguish
them in the English strings.xml with the case="N" attribute (N=1 and
higher), sync language files from the translator menu (existing
translations for the uncased string will simply be copied to all cases)
and change loc::gettext("...") to loc::gettext_case("...", 1),
loc::gettext_case("...", 2), etc.
2022-12-01 01:27:30 +01:00
|
|
|
default:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char* status_text;
|
|
|
|
if (gender == 3 && rescued)
|
|
|
|
{
|
|
|
|
status_text = loc::gettext("(that's you!)");
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
Add support for string cases in strings.xml (gendered Rescued/Missing)
I wanted to not complicate the system with different string cases (like
cgettext) if possible, and I have been able to keep the main strings a
simple English=Translation mapping thus far, but apparently strings
like "Rescued!" (which are one string in English), have to be
translated for the correct gender in some languages. So this was a good
time to add support for string cases anyway.
It's a number that can be given to a string to specify the specific
case it's used, to disambiguate identical English keys. In the case of
"Rescued!" and "Missing...", male versions of the string are case 1,
female versions are case 2, and Viridian being missing is case 3. Of
course, if a language doesn't need to use different variants, it can
simply fill in the same string for the different cases.
If any other string needs to switch to different cases: distinguish
them in the English strings.xml with the case="N" attribute (N=1 and
higher), sync language files from the translator menu (existing
translations for the uncased string will simply be copied to all cases)
and change loc::gettext("...") to loc::gettext_case("...", 1),
loc::gettext_case("...", 2), etc.
2022-12-01 01:27:30 +01:00
|
|
|
else if (rescued)
|
|
|
|
{
|
|
|
|
status_text = loc::gettext_case("Rescued!", gender);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
r=64; g=64; b=64;
|
|
|
|
status_text = loc::gettext_case("Missing...", gender);
|
|
|
|
}
|
|
|
|
|
2023-01-20 20:24:41 +01:00
|
|
|
font::print(0, x, y, status_text, r, g, b);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
Replace "by" for level authors with happy face
"by {author}" is a string that will cause a lot of localization-related
problems, which then become much worse when different languages and
levels can also need different fonts:
- If the author name is set to something in English instead of a name,
then it'll come out a bit weird if your VVVVVV is set to a different
language: "de various people", "por various people", etc. It's the
same problem with Discord bots completing "playing" or "watching" in
their statuses.
- Translators can't always fit "by" in two letters, and level creators
have understandably always assumed, and will continue to assume, that
"by" is two letters. So if you have your VVVVVV set to a language that
translates "by" as something long, then:
| by Various People and Others |
...may suddenly show up as something like:
|thorer Various People and Othe|
- "by" and author may need mutually incompatible fonts. For example, a
Japanese level in a Korean VVVVVV needs to be displayed with "by" in
Korean characters and the author name with Japanese characters, which
would need some very special code since languages may want to add
text both before and after the name.
- It's very possible that some languages can't translate "by" without
knowing the gender of the name, and I know some languages even
inflect names in really interesting ways (adding and even replacing
letters in first names, surnames, and anything in between, depending
on gender and what else is in the sentence).
So to solve all of this, the "by" is now replaced by a 10x10 face from
sprites.png, like a :viridian: emote. See it as a kind of avatar next
to a username, to clarify and assert that this line is for the author's
name. It should be a fairly obvious/recognizable icon, it fixes all the
above problems, and it's a bonus that we now have more happy faces in
VVVVVV.
2023-01-31 00:41:46 +01:00
|
|
|
void Graphics::print_level_creator(
|
|
|
|
const uint32_t print_flags,
|
|
|
|
const int y,
|
|
|
|
const std::string& creator,
|
|
|
|
const uint8_t r,
|
|
|
|
const uint8_t g,
|
|
|
|
const uint8_t b
|
|
|
|
) {
|
|
|
|
/* We now display a face instead of "by {author}" for several reasons:
|
|
|
|
* - "by" may be in a different language than the author and look weird ("por various people")
|
|
|
|
* - "by" will be longer in different languages and break the limit that levels assume
|
|
|
|
* - "by" and author may need mutually incompatible fonts, e.g. Japanese level in Korean VVVVVV
|
|
|
|
* - avoids likely grammar problems: male/female difference, name inflection in user-written text...
|
|
|
|
* - it makes sense to make it a face
|
|
|
|
* - if anyone is sad about this decision, the happy face will cheer them up anyway :D */
|
|
|
|
int width_for_face = 17;
|
2023-03-05 00:32:58 +01:00
|
|
|
int total_width = width_for_face + font::len(print_flags, creator.c_str());
|
Replace "by" for level authors with happy face
"by {author}" is a string that will cause a lot of localization-related
problems, which then become much worse when different languages and
levels can also need different fonts:
- If the author name is set to something in English instead of a name,
then it'll come out a bit weird if your VVVVVV is set to a different
language: "de various people", "por various people", etc. It's the
same problem with Discord bots completing "playing" or "watching" in
their statuses.
- Translators can't always fit "by" in two letters, and level creators
have understandably always assumed, and will continue to assume, that
"by" is two letters. So if you have your VVVVVV set to a language that
translates "by" as something long, then:
| by Various People and Others |
...may suddenly show up as something like:
|thorer Various People and Othe|
- "by" and author may need mutually incompatible fonts. For example, a
Japanese level in a Korean VVVVVV needs to be displayed with "by" in
Korean characters and the author name with Japanese characters, which
would need some very special code since languages may want to add
text both before and after the name.
- It's very possible that some languages can't translate "by" without
knowing the gender of the name, and I know some languages even
inflect names in really interesting ways (adding and even replacing
letters in first names, surnames, and anything in between, depending
on gender and what else is in the sentence).
So to solve all of this, the "by" is now replaced by a 10x10 face from
sprites.png, like a :viridian: emote. See it as a kind of avatar next
to a username, to clarify and assert that this line is for the author's
name. It should be a fairly obvious/recognizable icon, it fixes all the
above problems, and it's a bonus that we now have more happy faces in
VVVVVV.
2023-01-31 00:41:46 +01:00
|
|
|
int face_x = (SCREEN_WIDTH_PIXELS-total_width)/2;
|
|
|
|
set_texture_color_mod(grphx.im_sprites, r, g, b);
|
|
|
|
draw_texture_part(grphx.im_sprites, face_x, y-1, 7, 2, 10, 10, 1, 1);
|
|
|
|
set_texture_color_mod(grphx.im_sprites, 255, 255, 255);
|
|
|
|
font::print(print_flags, face_x+width_for_face, y, creator, r, g, b);
|
|
|
|
}
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
int Graphics::set_render_target(SDL_Texture* texture)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
const int result = SDL_SetRenderTarget(gameScreen.m_renderer, texture);
|
|
|
|
if (result != 0)
|
2020-09-10 07:35:35 +02:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
WHINE_ONCE_ARGS(("Could not set render target: %s", SDL_GetError()));
|
2020-09-10 07:35:35 +02:00
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
return result;
|
|
|
|
}
|
2020-09-10 07:35:35 +02:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
int Graphics::set_texture_color_mod(SDL_Texture* texture, const Uint8 r, const Uint8 g, const Uint8 b)
|
|
|
|
{
|
|
|
|
const int result = SDL_SetTextureColorMod(texture, r, g, b);
|
|
|
|
if (result != 0)
|
|
|
|
{
|
|
|
|
WHINE_ONCE_ARGS(("Could not set texture color mod: %s", SDL_GetError()));
|
|
|
|
}
|
|
|
|
return result;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
int Graphics::set_texture_alpha_mod(SDL_Texture* texture, const Uint8 alpha)
|
2020-05-02 01:40:35 +02:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
const int result = SDL_SetTextureAlphaMod(texture, alpha);
|
|
|
|
if (result != 0)
|
2020-09-10 07:35:35 +02:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
WHINE_ONCE_ARGS(("Could not set texture alpha mod: %s", SDL_GetError()));
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::query_texture(SDL_Texture* texture, Uint32* format, int* access, int* w, int* h)
|
|
|
|
{
|
|
|
|
const int result = SDL_QueryTexture(texture, format, access, w, h);
|
|
|
|
if (result != 0)
|
|
|
|
{
|
|
|
|
WHINE_ONCE_ARGS(("Could not query texture: %s", SDL_GetError()));
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::set_blendmode(const SDL_BlendMode blendmode)
|
|
|
|
{
|
|
|
|
const int result = SDL_SetRenderDrawBlendMode(gameScreen.m_renderer, blendmode);
|
|
|
|
if (result != 0)
|
|
|
|
{
|
|
|
|
WHINE_ONCE_ARGS(("Could not set draw mode: %s", SDL_GetError()));
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::set_blendmode(SDL_Texture* texture, const SDL_BlendMode blendmode)
|
|
|
|
{
|
|
|
|
const int result = SDL_SetTextureBlendMode(texture, blendmode);
|
|
|
|
if (result != 0)
|
|
|
|
{
|
|
|
|
WHINE_ONCE_ARGS(("Could not set texture blend mode: %s", SDL_GetError()));
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::clear(const int r, const int g, const int b, const int a)
|
|
|
|
{
|
|
|
|
set_color(r, g, b, a);
|
|
|
|
|
|
|
|
const int result = SDL_RenderClear(gameScreen.m_renderer);
|
|
|
|
if (result != 0)
|
|
|
|
{
|
|
|
|
WHINE_ONCE_ARGS(("Could not clear current render target: %s", SDL_GetError()));
|
2020-09-10 07:35:35 +02:00
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
return result;
|
|
|
|
}
|
2020-09-10 07:35:35 +02:00
|
|
|
|
2023-03-18 23:24:14 +01:00
|
|
|
int Graphics::clear(void)
|
2023-01-07 19:28:07 +01:00
|
|
|
{
|
|
|
|
return clear(0, 0, 0, 255);
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::copy_texture(SDL_Texture* texture, const SDL_Rect* src, const SDL_Rect* dest)
|
|
|
|
{
|
|
|
|
const int result = SDL_RenderCopy(gameScreen.m_renderer, texture, src, dest);
|
|
|
|
if (result != 0)
|
|
|
|
{
|
|
|
|
WHINE_ONCE_ARGS(("Could not copy texture: %s", SDL_GetError()));
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::copy_texture(SDL_Texture* texture, const SDL_Rect* src, const SDL_Rect* dest, const double angle, const SDL_Point* center, const SDL_RendererFlip flip)
|
|
|
|
{
|
|
|
|
const int result = SDL_RenderCopyEx(gameScreen.m_renderer, texture, src, dest, angle, center, flip);
|
|
|
|
if (result != 0)
|
|
|
|
{
|
|
|
|
WHINE_ONCE_ARGS(("Could not copy texture: %s", SDL_GetError()));
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::set_color(const Uint8 r, const Uint8 g, const Uint8 b, const Uint8 a)
|
|
|
|
{
|
|
|
|
const int result = SDL_SetRenderDrawColor(gameScreen.m_renderer, r, g, b, a);
|
|
|
|
if (result != 0)
|
|
|
|
{
|
|
|
|
WHINE_ONCE_ARGS(("Could not set draw color: %s", SDL_GetError()));
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::set_color(const Uint8 r, const Uint8 g, const Uint8 b)
|
|
|
|
{
|
|
|
|
return set_color(r, g, b, 255);
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::set_color(const SDL_Color color)
|
|
|
|
{
|
|
|
|
return set_color(color.r, color.g, color.b, color.a);
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::fill_rect(const SDL_Rect* rect, const int r, const int g, const int b, const int a)
|
|
|
|
{
|
|
|
|
set_color(r, g, b, a);
|
|
|
|
|
|
|
|
const int result = SDL_RenderFillRect(gameScreen.m_renderer, rect);
|
|
|
|
if (result != 0)
|
|
|
|
{
|
|
|
|
WHINE_ONCE_ARGS(("Could not draw filled rectangle: %s", SDL_GetError()));
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::fill_rect(const int r, const int g, const int b, const int a)
|
|
|
|
{
|
|
|
|
return fill_rect(NULL, r, g, b, a);
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::fill_rect(const SDL_Rect* rect, const int r, const int g, const int b)
|
|
|
|
{
|
|
|
|
return fill_rect(rect, r, g, b, 255);
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::fill_rect(const int r, const int g, const int b)
|
|
|
|
{
|
|
|
|
return fill_rect(NULL, r, g, b, 255);
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::fill_rect(const SDL_Rect* rect, const SDL_Color color)
|
|
|
|
{
|
|
|
|
return fill_rect(rect, color.r, color.g, color.b, color.a);
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::fill_rect(const int x, const int y, const int w, const int h, const int r, const int g, const int b, const int a)
|
|
|
|
{
|
|
|
|
const SDL_Rect rect = {x, y, w, h};
|
|
|
|
return fill_rect(&rect, r, g, b, a);
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::fill_rect(const int x, const int y, const int w, const int h, const int r, const int g, const int b)
|
|
|
|
{
|
|
|
|
return fill_rect(x, y, w, h, r, g, b, 255);
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::fill_rect(const SDL_Color color)
|
|
|
|
{
|
|
|
|
return fill_rect(NULL, color);
|
|
|
|
}
|
|
|
|
|
|
|
|
int Graphics::fill_rect(const int x, const int y, const int w, const int h, const SDL_Color color)
|
|
|
|
{
|
|
|
|
return fill_rect(x, y, w, h, color.r, color.g, color.b, color.a);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::draw_sprite(const int x, const int y, const int t, const int r, const int g, const int b)
|
|
|
|
{
|
|
|
|
draw_grid_tile(grphx.im_sprites, t, x, y, sprites_rect.w, sprites_rect.h, r, g, b);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::draw_sprite(const int x, const int y, const int t, const SDL_Color color)
|
|
|
|
{
|
|
|
|
draw_grid_tile(grphx.im_sprites, t, x, y, sprites_rect.w, sprites_rect.h, color);
|
|
|
|
}
|
|
|
|
|
2023-03-04 01:02:53 +01:00
|
|
|
void Graphics::scroll_texture(SDL_Texture* texture, SDL_Texture* temp, const int x, const int y)
|
2023-01-07 19:28:07 +01:00
|
|
|
{
|
2023-03-04 01:02:53 +01:00
|
|
|
SDL_Texture* target = SDL_GetRenderTarget(gameScreen.m_renderer);
|
2023-01-07 19:28:07 +01:00
|
|
|
SDL_Rect texture_rect = {0, 0, 0, 0};
|
|
|
|
SDL_QueryTexture(texture, NULL, NULL, &texture_rect.w, &texture_rect.h);
|
|
|
|
|
2023-03-04 01:02:53 +01:00
|
|
|
const SDL_Rect src = {0, 0, texture_rect.w, texture_rect.h};
|
|
|
|
const SDL_Rect dest = {x, y, texture_rect.w, texture_rect.h};
|
2023-01-07 19:28:07 +01:00
|
|
|
|
2023-03-04 01:02:53 +01:00
|
|
|
set_render_target(temp);
|
|
|
|
clear();
|
|
|
|
copy_texture(texture, &src, &dest);
|
|
|
|
set_render_target(target);
|
|
|
|
copy_texture(temp, &src, &src);
|
2020-05-02 01:40:35 +02:00
|
|
|
}
|
|
|
|
|
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 Graphics::shouldrecoloroneway(const int tilenum, const bool mounted)
|
2021-03-06 08:55:35 +01:00
|
|
|
{
|
|
|
|
return (tilenum >= 14 && tilenum <= 17
|
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
|
|
|
&& (!mounted
|
2021-02-21 00:40:11 +01:00
|
|
|
|| cl.onewaycol_override));
|
2021-03-06 08:55:35 +01:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2020-04-02 00:42:22 +02:00
|
|
|
void Graphics::drawtile( int x, int y, int t )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-06-30 20:47:22 +02:00
|
|
|
#if !defined(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
|
|
|
if (shouldrecoloroneway(t, tiles1_mounted))
|
2020-06-30 20:47:22 +02:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_tiles_tint, t, x, y, tiles_rect.w, tiles_rect.h, cl.getonewaycol());
|
2020-06-30 20:47:22 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_tiles, t, x, y, tiles_rect.w, tiles_rect.h);
|
2020-06-30 20:47:22 +02:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2020-04-02 00:47:35 +02:00
|
|
|
void Graphics::drawtile2( int x, int y, int t )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-06-30 20:47:22 +02:00
|
|
|
#if !defined(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
|
|
|
if (shouldrecoloroneway(t, tiles2_mounted))
|
2020-06-30 20:47:22 +02:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_tiles2_tint, t, x, y, tiles_rect.w, tiles_rect.h, cl.getonewaycol());
|
2020-06-30 20:47:22 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_tiles2, t, x, y, tiles_rect.w, tiles_rect.h);
|
2020-06-30 20:47:22 +02:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-04 04:13:08 +02:00
|
|
|
void Graphics::drawtile3( int x, int y, int t, int off, int height_subtract /*= 0*/ )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-08-04 03:58:53 +02:00
|
|
|
t += off * 30;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
// Can't use drawgridtile because we want to draw a slice of the tile,
|
|
|
|
// so do the logic ourselves (except include height_subtract in the final call)
|
|
|
|
|
|
|
|
int width;
|
|
|
|
if (query_texture(grphx.im_tiles3, NULL, NULL, &width, NULL) != 0)
|
2020-06-14 03:37:18 +02:00
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
const int x2 = (t % (width / 8)) * 8;
|
|
|
|
const int y2 = (t / (width / 8)) * 8;
|
|
|
|
draw_texture_part(grphx.im_tiles3, x, y, x2, y2, 8, 8 - height_subtract, 1, 1);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::drawtowertile( int x, int y, int t )
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_tiles2, t, x, y, tiles_rect.w, tiles_rect.h);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2020-11-03 00:05:24 +01:00
|
|
|
void Graphics::drawtowertile3( int x, int y, int t, TowerBG& bg_obj )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
t += bg_obj.colstate * 30;
|
|
|
|
|
|
|
|
draw_grid_tile(grphx.im_tiles3, t, x, y, tiles_rect.w, tiles_rect.h);
|
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 Graphics::drawgui(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-03-19 21:31:53 +01:00
|
|
|
int text_sign;
|
2021-03-19 21:34:13 +01:00
|
|
|
int crew_yp;
|
|
|
|
int crew_sprite;
|
2021-09-06 09:36:35 +02:00
|
|
|
size_t i;
|
|
|
|
|
2021-03-19 21:31:53 +01:00
|
|
|
if (flipmode)
|
|
|
|
{
|
|
|
|
text_sign = -1;
|
2021-03-19 21:34:13 +01:00
|
|
|
crew_yp = 64 + 48 + 4;
|
|
|
|
crew_sprite = 6;
|
2021-03-19 21:31:53 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
text_sign = 1;
|
2021-03-19 21:34:13 +01:00
|
|
|
crew_yp = 64 + 32 + 4;
|
|
|
|
crew_sprite = 0;
|
2021-03-19 21:31:53 +01:00
|
|
|
}
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
//Draw all the textboxes to the screen
|
2021-09-13 06:02:15 +02:00
|
|
|
for (i = 0; i<textboxes.size(); i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-03-19 21:31:53 +01:00
|
|
|
int text_yoff;
|
2021-03-20 03:51:36 +01:00
|
|
|
int yp;
|
Fix text box deltaframe flashing on deltaframes after fully opaque
So #434 didn't end up solving the deltaframe flashing fully, only
reduced the chances that it could happen.
I've had the Level Complete image flash a few times when the Game Saved
text box pops up. This seems to be because the Level Complete image is
based off of the text box being at y-position 12, and the Game Saved
text box is also at y-position 12. Level Complete only gets drawn if the
text box additionally has a red channel value of 165, and the Game Saved
text box has a red channel value of 174. However, there is a check that
the text box be fully opaque first before drawing special images. So
what went wrong?
Well, after thinking about it for a while, I realized that even though
there is indeed an opaqueness check, the alpha of the text box updates
BEFORE it gets drawn. And during the deltaframes immediately after it
gets updated, the text box is considered fully opaque. It's completely
possible for the linear interpolation to end up with a red channel value
of 165 during these deltaframes, while the text box is opaque as well.
As always, it helps if you have a high refresh rate, and run the game
under 40% slowdown.
Anyways, so what's the final fix for this issue? Well, use the text box
'target' RGB values instead - its tr/tg/tb attributes instead of its
r/g/b attributes. They are not subject to interpolation and so are
completely reliable. The opaqueness check should still be kept, though,
because the target values don't account for opaqueness. And this way, we
get no more deltaframe flashes during text box fades.
An even better fix would be to not use magic RGB values to draw special
images... but that'd be something to do later.
2021-03-21 20:49:14 +01:00
|
|
|
bool opaque;
|
2023-01-13 05:11:39 +01:00
|
|
|
int font_height = font::height(textboxes[i].print_flags);
|
2021-03-19 21:31:53 +01:00
|
|
|
if (flipmode)
|
|
|
|
{
|
2023-01-13 05:11:39 +01:00
|
|
|
text_yoff = 8 + (textboxes[i].lines.size() - 1) * font_height;
|
2021-03-19 21:31:53 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
text_yoff = 8;
|
|
|
|
}
|
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
yp = textboxes[i].yp;
|
|
|
|
if (flipmode && textboxes[i].flipme)
|
2021-03-20 03:51:36 +01:00
|
|
|
{
|
2023-01-13 05:11:39 +01:00
|
|
|
yp = SCREEN_HEIGHT_PIXELS - yp - 16 - textboxes[i].lines.size() * font_height;
|
2021-03-20 03:51:36 +01:00
|
|
|
}
|
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
if (textboxes[i].r == 0 && textboxes[i].g == 0 && textboxes[i].b == 0)
|
2020-04-04 02:26:29 +02:00
|
|
|
{
|
2023-01-17 22:18:39 +01:00
|
|
|
/* To avoid the outlines for different lines overlapping the text itself,
|
|
|
|
* first draw all the outlines and then draw the text. */
|
2021-09-06 09:36:35 +02:00
|
|
|
size_t j;
|
2021-09-13 06:02:15 +02:00
|
|
|
for (j = 0; j < textboxes[i].lines.size(); j++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-17 22:18:39 +01:00
|
|
|
font::print(
|
|
|
|
textboxes[i].print_flags | PR_CJK_LOW | PR_BOR,
|
|
|
|
textboxes[i].xp + 8,
|
|
|
|
yp + text_yoff + text_sign * (j * font_height),
|
|
|
|
textboxes[i].lines[j],
|
|
|
|
0, 0, 0
|
|
|
|
);
|
|
|
|
}
|
|
|
|
for (j = 0; j < textboxes[i].lines.size(); j++)
|
|
|
|
{
|
|
|
|
font::print(
|
|
|
|
textboxes[i].print_flags | PR_CJK_LOW,
|
|
|
|
textboxes[i].xp + 8,
|
|
|
|
yp + text_yoff + text_sign * (j * font_height),
|
|
|
|
textboxes[i].lines[j],
|
|
|
|
196, 196, 255 - help.glow
|
|
|
|
);
|
2020-04-04 02:26:29 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
const float tl_lerp = lerp(textboxes[i].prev_tl, textboxes[i].tl);
|
|
|
|
const int r = textboxes[i].r * tl_lerp;
|
|
|
|
const int g = textboxes[i].g * tl_lerp;
|
|
|
|
const int b = textboxes[i].b * tl_lerp;
|
2021-09-06 09:36:35 +02:00
|
|
|
size_t j;
|
|
|
|
|
2023-01-12 05:27:52 +01:00
|
|
|
drawpixeltextbox(textboxes[i].xp, yp, textboxes[i].w, textboxes[i].h, r, g, b);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
for (j = 0; j < textboxes[i].lines.size(); j++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-12 05:27:52 +01:00
|
|
|
font::print(
|
Replace PR_COLORGLYPH_BRI(a) and PR_ALPHA(a) with PR_BRIGHTNESS(a)
There used to be two ways of fading in/out text in VVVVVV:
- Local code that modifies the R, G and B values of the text
- Keeping the RGB values the same and using the alpha channel
The latter approach is only used once, for [Press ENTER to return to
editor]. The former approach causes problems with colored (button)
glyphs: there's no way for the print function to tell from the RGB
values whether a color is "full Viridian-cyan" or "Viridian-cyan faded
out 50%", so I added the flag PR_COLORGLYPH_BRI(value) to tell the
print function that the color brightness is reduced to match the
brightness of colored glyphs to the brightness of the rest of the text.
However, there were already plans to make the single use of alpha
consistent with the rest of the game and the style, so PR_ALPHA(value)
could be removed, as well as the bit signifying whether the brightness
or alpha value is used. For the editor text, I simply copied the "Press
{button} to teleport" behavior of hiding the text completely if it
becomes darker than 100/255.
Another simplification is to make the print function handle not just
the brightness of the color glyphs while local code handled the
brightness of the normal text color, but to make the print function
handle both. That way, the callsite can simply pass in the full colors
and the brightness flag, and the flag name can be made a lot simpler as
well: PR_BRIGHTNESS(value).
2023-01-31 02:22:43 +01:00
|
|
|
textboxes[i].print_flags | PR_BRIGHTNESS(tl_lerp*255) | PR_CJK_LOW,
|
2023-01-12 05:27:52 +01:00
|
|
|
textboxes[i].xp + 8,
|
2023-01-13 05:11:39 +01:00
|
|
|
yp + text_yoff + text_sign * (j * font_height),
|
2023-01-12 05:27:52 +01:00
|
|
|
textboxes[i].lines[j],
|
Replace PR_COLORGLYPH_BRI(a) and PR_ALPHA(a) with PR_BRIGHTNESS(a)
There used to be two ways of fading in/out text in VVVVVV:
- Local code that modifies the R, G and B values of the text
- Keeping the RGB values the same and using the alpha channel
The latter approach is only used once, for [Press ENTER to return to
editor]. The former approach causes problems with colored (button)
glyphs: there's no way for the print function to tell from the RGB
values whether a color is "full Viridian-cyan" or "Viridian-cyan faded
out 50%", so I added the flag PR_COLORGLYPH_BRI(value) to tell the
print function that the color brightness is reduced to match the
brightness of colored glyphs to the brightness of the rest of the text.
However, there were already plans to make the single use of alpha
consistent with the rest of the game and the style, so PR_ALPHA(value)
could be removed, as well as the bit signifying whether the brightness
or alpha value is used. For the editor text, I simply copied the "Press
{button} to teleport" behavior of hiding the text completely if it
becomes darker than 100/255.
Another simplification is to make the print function handle not just
the brightness of the color glyphs while local code handled the
brightness of the normal text color, but to make the print function
handle both. That way, the callsite can simply pass in the full colors
and the brightness flag, and the flag name can be made a lot simpler as
well: PR_BRIGHTNESS(value).
2023-01-31 02:22:43 +01:00
|
|
|
textboxes[i].r, textboxes[i].g, textboxes[i].b
|
2023-01-12 05:27:52 +01:00
|
|
|
);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-04-04 02:26:29 +02:00
|
|
|
}
|
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
opaque = textboxes[i].tl >= 1.0;
|
Remove allowspecial, replace with opaqueness check
When I added the over-30-FPS mode, I kept running into this problem
where the special images of text boxes would render during the
deltaframes of fade-in/fade-out animations, even though they shouldn't
be. So I simply added a flag to the text box that enables drawing these
special images.
However, this doesn't solve the problem fully, and there's still a small
chance that a special-image text box could draw another special image
during its deltaframes. It's really rare and you have to have your
deltaframe luck juuuuuust right (or you could use libTAS, probably), but
it helps to be in 40% slowmode and have a high refresh rate (which, if
it isn't a multiple of 30, you should disable VSync, too, in order to
not have a low framerate).
So instead, special images will only be drawn if the text box has fully
faded in completely. That solves the issue completely.
2020-08-05 05:42:43 +02:00
|
|
|
|
Fix text box deltaframe flashing on deltaframes after fully opaque
So #434 didn't end up solving the deltaframe flashing fully, only
reduced the chances that it could happen.
I've had the Level Complete image flash a few times when the Game Saved
text box pops up. This seems to be because the Level Complete image is
based off of the text box being at y-position 12, and the Game Saved
text box is also at y-position 12. Level Complete only gets drawn if the
text box additionally has a red channel value of 165, and the Game Saved
text box has a red channel value of 174. However, there is a check that
the text box be fully opaque first before drawing special images. So
what went wrong?
Well, after thinking about it for a while, I realized that even though
there is indeed an opaqueness check, the alpha of the text box updates
BEFORE it gets drawn. And during the deltaframes immediately after it
gets updated, the text box is considered fully opaque. It's completely
possible for the linear interpolation to end up with a red channel value
of 165 during these deltaframes, while the text box is opaque as well.
As always, it helps if you have a high refresh rate, and run the game
under 40% slowdown.
Anyways, so what's the final fix for this issue? Well, use the text box
'target' RGB values instead - its tr/tg/tb attributes instead of its
r/g/b attributes. They are not subject to interpolation and so are
completely reliable. The opaqueness check should still be kept, though,
because the target values don't account for opaqueness. And this way, we
get no more deltaframe flashes during text box fades.
An even better fix would be to not use magic RGB values to draw special
images... but that'd be something to do later.
2021-03-21 20:49:14 +01:00
|
|
|
if (!opaque)
|
|
|
|
{
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
if (textboxes[i].yp == 12 && textboxes[i].r == 165)
|
2020-04-04 02:26:29 +02:00
|
|
|
{
|
2022-12-30 23:39:12 +01:00
|
|
|
// Level complete
|
|
|
|
const char* english = "Level Complete!";
|
|
|
|
const char* translation = loc::gettext(english);
|
|
|
|
if (SDL_strcmp(english, translation) != 0
|
|
|
|
&& !(flipmode && fliplevelcomplete_mounted)
|
|
|
|
&& !(!flipmode && levelcomplete_mounted)
|
|
|
|
)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2022-12-30 23:39:12 +01:00
|
|
|
int sc = 2;
|
|
|
|
int y = 28;
|
2023-01-17 04:41:12 +01:00
|
|
|
if (font::len(0, translation) > 144)
|
2022-12-30 23:39:12 +01:00
|
|
|
{
|
|
|
|
// We told translators how long it could be... Ah well, mitigate the damage.
|
|
|
|
sc = 1;
|
|
|
|
y += 4;
|
|
|
|
}
|
|
|
|
if (flipmode)
|
|
|
|
{
|
|
|
|
y = 240 - y - 8*sc;
|
|
|
|
}
|
2023-02-25 03:39:59 +01:00
|
|
|
font::print((sc==2 ? PR_2X : PR_1X) | PR_CEN, -1, y, translation, 164, 164, 255);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2022-12-30 23:39:12 +01:00
|
|
|
if (flipmode)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
drawimage(IMAGE_FLIPLEVELCOMPLETE, 0, 180, true);
|
2022-12-30 23:39:12 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
drawimage(IMAGE_LEVELCOMPLETE, 0, 12, true);
|
2022-12-30 23:39:12 +01:00
|
|
|
}
|
2020-04-04 02:26:29 +02:00
|
|
|
}
|
|
|
|
}
|
2021-09-13 06:02:15 +02:00
|
|
|
else if (textboxes[i].yp == 12 && textboxes[i].g == 165)
|
2020-04-04 02:26:29 +02:00
|
|
|
{
|
2022-12-30 23:39:12 +01:00
|
|
|
// Game complete
|
|
|
|
const char* english = "Game Complete!";
|
|
|
|
const char* translation = loc::gettext(english);
|
|
|
|
if (SDL_strcmp(english, translation) != 0
|
|
|
|
&& !(flipmode && flipgamecomplete_mounted)
|
|
|
|
&& !(!flipmode && gamecomplete_mounted)
|
|
|
|
)
|
2020-04-04 02:26:29 +02:00
|
|
|
{
|
2022-12-30 23:39:12 +01:00
|
|
|
int sc = 2;
|
|
|
|
int y = 28;
|
2023-01-17 04:41:12 +01:00
|
|
|
if (font::len(0, translation) > 144)
|
2022-12-30 23:39:12 +01:00
|
|
|
{
|
|
|
|
// We told translators how long it could be... Ah well, mitigate the damage.
|
|
|
|
sc = 1;
|
|
|
|
y += 4;
|
|
|
|
}
|
|
|
|
if (flipmode)
|
|
|
|
{
|
|
|
|
y = 240 - y - 8*sc;
|
|
|
|
}
|
2023-02-25 03:39:59 +01:00
|
|
|
font::print((sc==2 ? PR_2X : PR_1X) | PR_CEN, -1, y, translation, 196, 196, 243);
|
2020-04-04 02:26:29 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2022-12-30 23:39:12 +01:00
|
|
|
if (flipmode)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
drawimage(IMAGE_FLIPGAMECOMPLETE, 0, 180, true);
|
2022-12-30 23:39:12 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
drawimage(IMAGE_GAMECOMPLETE, 0, 12, true);
|
2022-12-30 23:39:12 +01:00
|
|
|
}
|
2020-04-04 02:26:29 +02:00
|
|
|
}
|
|
|
|
}
|
2022-12-30 23:39:12 +01:00
|
|
|
int crew_xp = textboxes[i].xp+20 - 6;
|
2021-09-13 06:02:15 +02:00
|
|
|
if (textboxes[i].r == 175 && textboxes[i].g == 175)
|
2020-04-04 02:26:29 +02:00
|
|
|
{
|
2021-03-19 21:34:13 +01:00
|
|
|
//purple guy
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(crew_xp, crew_yp, crew_sprite, 220- help.glow/4 - textboxes[i].rand, 120- help.glow/4, 210 - help.glow/4);
|
2020-04-04 02:26:29 +02:00
|
|
|
}
|
2021-09-13 06:02:15 +02:00
|
|
|
else if (textboxes[i].r == 175 && textboxes[i].b == 175)
|
2020-04-04 02:26:29 +02:00
|
|
|
{
|
2021-03-19 21:34:13 +01:00
|
|
|
//red guy
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(crew_xp, crew_yp, crew_sprite, 255 - help.glow/8, 70 - help.glow/4, 70 - help.glow / 4);
|
2021-03-19 21:34:13 +01:00
|
|
|
}
|
2021-09-13 06:02:15 +02:00
|
|
|
else if (textboxes[i].r == 175)
|
2021-03-19 21:34:13 +01:00
|
|
|
{
|
|
|
|
//green guy
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(crew_xp, crew_yp, crew_sprite, 120 - help.glow / 4 - textboxes[i].rand, 220 - help.glow / 4, 120 - help.glow / 4);
|
2021-03-19 21:34:13 +01:00
|
|
|
}
|
2021-09-13 06:02:15 +02:00
|
|
|
else if (textboxes[i].g == 175)
|
2021-03-19 21:34:13 +01:00
|
|
|
{
|
|
|
|
//yellow guy
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(crew_xp, crew_yp, crew_sprite, 220- help.glow/4 - textboxes[i].rand, 210 - help.glow/4, 120- help.glow/4);
|
2021-03-19 21:34:13 +01:00
|
|
|
}
|
2021-09-13 06:02:15 +02:00
|
|
|
else if (textboxes[i].b == 175)
|
2021-03-19 21:34:13 +01:00
|
|
|
{
|
|
|
|
//blue guy
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(crew_xp, crew_yp, crew_sprite, 75, 75, 255- help.glow/4 - textboxes[i].rand);
|
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 Graphics::updatetextboxes(void)
|
2020-04-29 03:38:43 +02:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
for (size_t i = 0; i < textboxes.size(); i++)
|
2020-04-29 03:38:43 +02:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes[i].update();
|
2020-04-29 03:38:43 +02:00
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
if (textboxes[i].tm == 2 && textboxes[i].tl <= 0.5)
|
2020-04-29 03:38:43 +02:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes.erase(textboxes.begin() + i);
|
2020-04-29 03:38:43 +02:00
|
|
|
i--;
|
|
|
|
continue;
|
|
|
|
}
|
2021-03-23 22:29:32 +01:00
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
if (textboxes[i].tl >= 1.0f
|
|
|
|
&& ((textboxes[i].r == 175 && textboxes[i].g == 175)
|
|
|
|
|| textboxes[i].r == 175
|
|
|
|
|| textboxes[i].g == 175
|
|
|
|
|| textboxes[i].b == 175)
|
|
|
|
&& (textboxes[i].r != 175 || textboxes[i].b != 175))
|
2021-03-23 22:29:32 +01:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes[i].rand = fRandom() * 20;
|
2021-03-23 22:29:32 +01:00
|
|
|
}
|
2020-04-29 03:38:43 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-01-02 05:16:08 +01:00
|
|
|
void Graphics::drawimagecol( int t, int xp, int yp, const SDL_Color ct, bool cent/*= false*/ )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
if (!INBOUNDS_ARR(t, images) || images[t] == NULL)
|
2020-06-14 03:37:53 +02:00
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
SDL_Rect trect;
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
trect.x = xp;
|
|
|
|
trect.y = yp;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
if (query_texture(images[t], NULL, NULL, &trect.w, &trect.h) != 0)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
return;
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
if (cent)
|
|
|
|
{
|
|
|
|
trect.x = (int) ((SCREEN_WIDTH_PIXELS - trect.w) / 2);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
set_texture_color_mod(images[t], ct.r, ct.g, ct.b);
|
|
|
|
draw_texture(images[t], trect.x, trect.y);
|
|
|
|
set_texture_color_mod(images[t], 255, 255, 255);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::drawimage( int t, int xp, int yp, bool cent/*=false*/ )
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
if (!INBOUNDS_ARR(t, images) || images[t] == NULL)
|
2020-06-14 03:37:53 +02:00
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
SDL_Rect trect;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
trect.x = xp;
|
|
|
|
trect.y = yp;
|
|
|
|
|
|
|
|
if (query_texture(images[t], NULL, NULL, &trect.w, &trect.h) != 0)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
if (cent)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
trect.x = (int) ((SCREEN_WIDTH_PIXELS - trect.w) / 2);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_texture(images[t], trect.x, trect.y);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::drawpartimage(const int t, const int xp, const int yp, const int wp, const int hp)
|
|
|
|
{
|
|
|
|
if (!INBOUNDS_ARR(t, images) || images[t] == NULL)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
draw_texture_part(images[t], xp, yp, 0, 0, wp, hp, 1, 1);
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
void Graphics::draw_texture(SDL_Texture* image, const int x, const int y)
|
|
|
|
{
|
|
|
|
int w, h;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
if (query_texture(image, NULL, NULL, &w, &h) != 0)
|
|
|
|
{
|
|
|
|
return;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
const SDL_Rect dstrect = {x, y, w, h};
|
|
|
|
|
|
|
|
copy_texture(image, NULL, &dstrect);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
void Graphics::draw_texture_part(SDL_Texture* image, const int x, const int y, const int x2, const int y2, const int w, const int h, const int scalex, const int scaley)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
const SDL_Rect srcrect = {x2, y2, w, h};
|
2020-06-14 03:37:53 +02:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
int flip = SDL_FLIP_NONE;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
if (scalex < 0)
|
|
|
|
{
|
|
|
|
flip |= SDL_FLIP_HORIZONTAL;
|
|
|
|
}
|
|
|
|
if (scaley < 0)
|
|
|
|
{
|
|
|
|
flip |= SDL_FLIP_VERTICAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
const SDL_Rect dstrect = {x, y, w * SDL_abs(scalex), h * SDL_abs(scaley)};
|
|
|
|
|
|
|
|
copy_texture(image, &srcrect, &dstrect, 0, NULL, (SDL_RendererFlip) flip);
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
void Graphics::draw_grid_tile(SDL_Texture* texture, const int t, const int x, const int y, const int width, const int height, const int scalex, const int scaley)
|
|
|
|
{
|
|
|
|
int tex_width;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
if (query_texture(texture, NULL, NULL, &tex_width, NULL) != 0)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
const int x2 = (t % (tex_width / width)) * width;
|
|
|
|
const int y2 = (t / (tex_width / width)) * height;
|
|
|
|
draw_texture_part(texture, x, y, x2, y2, width, height, scalex, scaley);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::draw_grid_tile(
|
|
|
|
SDL_Texture* texture, const int t,
|
|
|
|
const int x, const int y, const int width, const int height
|
|
|
|
) {
|
|
|
|
draw_grid_tile(texture, t, x, y, width, height, 1, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::draw_grid_tile(
|
|
|
|
SDL_Texture* texture, const int t,
|
|
|
|
const int x, const int y, const int width, const int height,
|
|
|
|
const int r, const int g, const int b, const int a,
|
|
|
|
const int scalex, const int scaley
|
|
|
|
) {
|
|
|
|
set_texture_color_mod(texture, r, g, b);
|
|
|
|
set_texture_alpha_mod(texture, a);
|
|
|
|
draw_grid_tile(texture, t, x, y, width, height, scalex, scaley);
|
|
|
|
set_texture_color_mod(texture, 255, 255, 255);
|
|
|
|
set_texture_alpha_mod(texture, 255);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::draw_grid_tile(
|
|
|
|
SDL_Texture* texture, const int t,
|
|
|
|
const int x, const int y, const int width, const int height,
|
|
|
|
const int r, const int g, const int b, const int a
|
|
|
|
) {
|
|
|
|
draw_grid_tile(texture, t, x, y, width, height, r, g, b, a, 1, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::draw_grid_tile(
|
|
|
|
SDL_Texture* texture, const int t,
|
|
|
|
const int x, const int y, const int width, const int height,
|
|
|
|
const int r, const int g, const int b,
|
|
|
|
const int scalex, const int scaley
|
|
|
|
) {
|
|
|
|
draw_grid_tile(texture, t, x, y, width, height, r, g, b, 255, scalex, scaley);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::draw_grid_tile(
|
|
|
|
SDL_Texture* texture, const int t,
|
|
|
|
const int x, const int y, const int width, const int height,
|
|
|
|
const int r, const int g, const int b
|
|
|
|
) {
|
|
|
|
draw_grid_tile(texture, t, x, y, width, height, r, g, b, 255);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::draw_grid_tile(
|
|
|
|
SDL_Texture* texture, const int t,
|
|
|
|
const int x, const int y, const int width, const int height,
|
|
|
|
const SDL_Color color,
|
|
|
|
const int scalex, const int scaley
|
|
|
|
) {
|
|
|
|
draw_grid_tile(texture, t, x, y, width, height, color.r, color.g, color.b, color.a, scalex, scaley);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::draw_grid_tile(
|
|
|
|
SDL_Texture* texture, const int t,
|
|
|
|
const int x, const int y, const int width, const int height,
|
|
|
|
const SDL_Color color
|
|
|
|
) {
|
|
|
|
draw_grid_tile(texture, t, x, y, width, height, color, 1, 1);
|
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 Graphics::cutscenebars(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
const int usethispos = lerp(oldcutscenebarspos, cutscenebarspos);
|
2020-01-01 21:29:24 +01:00
|
|
|
if (showcutscenebars)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(0, 0, usethispos, 16, 0, 0, 0);
|
|
|
|
fill_rect(360-usethispos, 224, usethispos, 16, 0, 0, 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-04-29 02:17:13 +02:00
|
|
|
else if (cutscenebarspos > 0) //disappearing
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-04-29 02:17:13 +02:00
|
|
|
//draw
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(0, 0, usethispos, 16, 0, 0, 0);
|
|
|
|
fill_rect(360-usethispos, 224, usethispos, 16, 0, 0, 0);
|
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 Graphics::cutscenebarstimer(void)
|
2020-04-29 02:11:02 +02:00
|
|
|
{
|
2020-04-29 02:16:24 +02:00
|
|
|
oldcutscenebarspos = cutscenebarspos;
|
2020-04-29 02:11:02 +02:00
|
|
|
if (showcutscenebars)
|
|
|
|
{
|
|
|
|
cutscenebarspos += 25;
|
Remove `VVV_min/max` in favor of `SDL_min/max`
VVV_min/max are functions that only operate on ints, and SDL_min/max are
macros that operate on any type but double-evaluate everything.
I know I more-or-less said earlier that SDL_min/max were dumb but I've
changed my mind and think it's better to use them, taking care to make
sure you don't double-evaluate, rather than trying to generate your own
litany of functions with either your own hand-rolled generation macros,
C++ templates, C11 generics, or GCC extensions (that last one you'd
technically use in a macro but it doesn't really matter), all of which
have more downsides than just not double-evaluating.
And the upside of not double-evaluating is that you're disencouraged
from having really complicated single-line min/max expressions and
encouraged to precompute the values beforehand anyway so the final
min/max is more readable. And furthermore you'll notice when you
yourself end up doing double-evaluations anyway. I removed a couple
instances of Graphics::len() being double-evaluated in this commit (as
well as cleaned up some other min/max-using code). Although the only
downside to those double-evaluations was unnecessary computation,
rather than checking the wrong result or having multiple side effects,
thankfully, it's still good to minimize double-evaluations where
possible.
2021-12-23 01:43:31 +01:00
|
|
|
cutscenebarspos = SDL_min(cutscenebarspos, 361);
|
2020-04-29 02:11:02 +02:00
|
|
|
}
|
|
|
|
else if (cutscenebarspos > 0)
|
|
|
|
{
|
|
|
|
//disappearing
|
|
|
|
cutscenebarspos -= 25;
|
Remove `VVV_min/max` in favor of `SDL_min/max`
VVV_min/max are functions that only operate on ints, and SDL_min/max are
macros that operate on any type but double-evaluate everything.
I know I more-or-less said earlier that SDL_min/max were dumb but I've
changed my mind and think it's better to use them, taking care to make
sure you don't double-evaluate, rather than trying to generate your own
litany of functions with either your own hand-rolled generation macros,
C++ templates, C11 generics, or GCC extensions (that last one you'd
technically use in a macro but it doesn't really matter), all of which
have more downsides than just not double-evaluating.
And the upside of not double-evaluating is that you're disencouraged
from having really complicated single-line min/max expressions and
encouraged to precompute the values beforehand anyway so the final
min/max is more readable. And furthermore you'll notice when you
yourself end up doing double-evaluations anyway. I removed a couple
instances of Graphics::len() being double-evaluated in this commit (as
well as cleaned up some other min/max-using code). Although the only
downside to those double-evaluations was unnecessary computation,
rather than checking the wrong result or having multiple side effects,
thankfully, it's still good to minimize double-evaluations where
possible.
2021-12-23 01:43:31 +01:00
|
|
|
cutscenebarspos = SDL_max(cutscenebarspos, 0);
|
2020-04-29 02:11:02 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-03-20 07:08:35 +01:00
|
|
|
void Graphics::setbars(const int position)
|
|
|
|
{
|
|
|
|
cutscenebarspos = position;
|
|
|
|
oldcutscenebarspos = position;
|
|
|
|
}
|
|
|
|
|
2020-03-31 21:26:11 +02:00
|
|
|
void Graphics::drawcrewman( int x, int y, int t, bool act, bool noshift /*=false*/ )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
if (!act)
|
|
|
|
{
|
|
|
|
if (noshift)
|
|
|
|
{
|
|
|
|
if (flipmode)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(x, y, 14, col_crewinactive);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(x, y, 12, col_crewinactive);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (flipmode)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(x - 8, y, 14, col_crewinactive);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(x - 8, y, 12, col_crewinactive);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (flipmode) crewframe += 6;
|
|
|
|
|
|
|
|
switch(t)
|
|
|
|
{
|
|
|
|
case 0:
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(x, y, crewframe, col_crewcyan);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 1:
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(x, y, crewframe, col_crewpurple);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 2:
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(x, y, crewframe, col_crewyellow);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 3:
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(x, y, crewframe, col_crewred);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 4:
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(x, y, crewframe, col_crewgreen);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 5:
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_sprite(x, y, crewframe, col_crewblue);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (flipmode) crewframe -= 6;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-09-04 00:31:59 +02:00
|
|
|
void Graphics::drawpixeltextbox(
|
|
|
|
const int x,
|
|
|
|
const int y,
|
|
|
|
const int w,
|
|
|
|
const int h,
|
|
|
|
const int r,
|
|
|
|
const int g,
|
|
|
|
const int b
|
|
|
|
) {
|
|
|
|
int k;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(x, y, w, h, r/6, g/6, b/6);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2021-09-04 00:31:59 +02:00
|
|
|
/* Horizontal tiles */
|
|
|
|
for (k = 0; k < w/8 - 2; ++k)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-04 00:31:59 +02:00
|
|
|
drawcoloredtile(x + 8 + k*8, y, 41, r, g, b);
|
|
|
|
drawcoloredtile(x + 8 + k*8, y + h - 8, 46, r, g, b);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2021-09-04 00:04:25 +02:00
|
|
|
if (w % 8 != 0)
|
|
|
|
{
|
2021-09-04 00:31:59 +02:00
|
|
|
/* Fill in horizontal gap */
|
2021-09-04 00:04:25 +02:00
|
|
|
drawcoloredtile(x + w - 16, y, 41, r, g, b);
|
|
|
|
drawcoloredtile(x + w - 16, y + h - 8, 46, r, g, b);
|
|
|
|
}
|
|
|
|
|
2021-09-04 00:31:59 +02:00
|
|
|
/* Vertical tiles */
|
|
|
|
for (k = 0; k < h/8 - 2; ++k)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-04 00:31:59 +02:00
|
|
|
drawcoloredtile(x, y + 8 + k*8, 43, r, g, b);
|
|
|
|
drawcoloredtile(x + w - 8, y + 8 + k*8, 44, r, g, b);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2021-09-04 00:04:25 +02:00
|
|
|
if (h % 8 != 0)
|
|
|
|
{
|
2021-09-04 00:31:59 +02:00
|
|
|
/* Fill in vertical gap */
|
2021-09-04 00:04:25 +02:00
|
|
|
drawcoloredtile(x, y + h - 16, 43, r, g, b);
|
|
|
|
drawcoloredtile(x + w - 8, y + h - 16, 44, r, g, b);
|
|
|
|
}
|
|
|
|
|
2021-09-04 00:31:59 +02:00
|
|
|
/* Corners */
|
2020-01-01 21:29:24 +01:00
|
|
|
drawcoloredtile(x, y, 40, r, g, b);
|
2021-09-04 00:31:59 +02:00
|
|
|
drawcoloredtile(x + w - 8, y, 42, r, g, b);
|
|
|
|
drawcoloredtile(x, y + h - 8, 45, r, g, b);
|
|
|
|
drawcoloredtile(x + w - 8, y + h - 8, 47, r, g, b);
|
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 Graphics::textboxactive(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
//Remove all but the most recent textbox
|
2021-09-13 06:02:15 +02:00
|
|
|
for (int i = 0; i < (int) textboxes.size(); i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
if (m != i) textboxes[i].remove();
|
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 Graphics::textboxremovefast(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
//Remove all textboxes
|
2021-09-13 06:02:15 +02:00
|
|
|
for (size_t i = 0; i < textboxes.size(); i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes[i].removefast();
|
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 Graphics::textboxremove(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
//Remove all textboxes
|
2021-09-13 06:02:15 +02:00
|
|
|
for (size_t i = 0; i < textboxes.size(); i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes[i].remove();
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::textboxtimer( int t )
|
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
2020-06-28 19:40:58 +02:00
|
|
|
{
|
2021-02-24 00:21:29 +01:00
|
|
|
vlog_error("textboxtimer() out-of-bounds!");
|
2020-06-28 19:40:58 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes[m].timer=t;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2021-09-07 00:41:49 +02:00
|
|
|
void Graphics::addline( const std::string& t )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
2020-06-28 19:40:58 +02:00
|
|
|
{
|
2021-02-24 00:21:29 +01:00
|
|
|
vlog_error("addline() out-of-bounds!");
|
2020-06-28 19:40:58 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes[m].addline(t);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2022-11-30 18:56:44 +01:00
|
|
|
void Graphics::setlarge(bool large)
|
|
|
|
{
|
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
|
|
|
{
|
|
|
|
vlog_error("setlarge() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
textboxes[m].large = large;
|
|
|
|
}
|
|
|
|
|
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 Graphics::textboxadjust(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
2020-06-28 19:40:58 +02:00
|
|
|
{
|
2021-02-24 00:21:29 +01:00
|
|
|
vlog_error("textboxadjust() out-of-bounds!");
|
2020-06-28 19:40:58 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes[m].adjust();
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-03-20 04:03:08 +01:00
|
|
|
void Graphics::createtextboxreal(
|
2021-09-07 00:41:49 +02:00
|
|
|
const std::string& t,
|
2021-03-20 04:03:08 +01:00
|
|
|
int xp,
|
|
|
|
int yp,
|
|
|
|
int r,
|
|
|
|
int g,
|
|
|
|
int b,
|
|
|
|
bool flipme
|
|
|
|
) {
|
2021-09-13 06:02:15 +02:00
|
|
|
m = textboxes.size();
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
if(m<20)
|
|
|
|
{
|
2020-04-04 02:25:17 +02:00
|
|
|
textboxclass text;
|
2021-09-13 06:02:15 +02:00
|
|
|
text.lines.push_back(t);
|
2020-04-04 02:25:17 +02:00
|
|
|
text.xp = xp;
|
2023-03-05 00:32:58 +01:00
|
|
|
if (xp == -1) text.xp = 160 - ((font::len(PR_FONT_LEVEL, t.c_str()) / 2) + 8);
|
2020-04-04 02:25:17 +02:00
|
|
|
text.yp = yp;
|
|
|
|
text.initcol(r, g, b);
|
2021-03-20 04:03:08 +01:00
|
|
|
text.flipme = flipme;
|
2020-04-04 02:25:17 +02:00
|
|
|
text.resize();
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes.push_back(text);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-03-20 04:03:08 +01:00
|
|
|
void Graphics::createtextbox(
|
2021-09-07 00:41:49 +02:00
|
|
|
const std::string& t,
|
2021-03-20 04:03:08 +01:00
|
|
|
int xp,
|
|
|
|
int yp,
|
|
|
|
int r,
|
|
|
|
int g,
|
|
|
|
int b
|
|
|
|
) {
|
|
|
|
createtextboxreal(t, xp, yp, r, g, b, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::createtextboxflipme(
|
2021-09-07 00:41:49 +02:00
|
|
|
const std::string& t,
|
2021-03-20 04:03:08 +01:00
|
|
|
int xp,
|
|
|
|
int yp,
|
|
|
|
int r,
|
|
|
|
int g,
|
|
|
|
int b
|
|
|
|
) {
|
|
|
|
createtextboxreal(t, xp, yp, r, g, b, true);
|
|
|
|
}
|
|
|
|
|
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 Graphics::drawfade(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
const int usethisamount = lerp(oldfadeamount, fadeamount);
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
switch (fademode)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
case FADE_FULLY_BLACK:
|
|
|
|
case FADE_START_FADEIN:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(0, 0, 0);
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
break;
|
|
|
|
case FADE_FADING_OUT:
|
2020-07-03 11:40:57 +02:00
|
|
|
for (size_t i = 0; i < SDL_arraysize(fadebars); i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(fadebars[i], i * 16, usethisamount, 16, 0, 0, 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
break;
|
|
|
|
case FADE_FADING_IN:
|
2020-07-03 11:40:57 +02:00
|
|
|
for (size_t i = 0; i < SDL_arraysize(fadebars); i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(fadebars[i]-usethisamount, i * 16, 500, 16, 0, 0, 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
break;
|
|
|
|
case FADE_NONE:
|
|
|
|
case FADE_START_FADEOUT:
|
|
|
|
break;
|
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 Graphics::processfade(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-04-29 03:10:40 +02:00
|
|
|
oldfadeamount = fadeamount;
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
switch (fademode)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
case FADE_START_FADEOUT:
|
|
|
|
for (size_t i = 0; i < SDL_arraysize(fadebars); i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
fadebars[i] = -int(fRandom() * 12) * 8;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
setfade(0);
|
|
|
|
fademode = FADE_FADING_OUT;
|
|
|
|
break;
|
|
|
|
case FADE_FADING_OUT:
|
|
|
|
fadeamount += 24;
|
|
|
|
if (fadeamount > 416)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
fademode = FADE_FULLY_BLACK;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
break;
|
|
|
|
case FADE_START_FADEIN:
|
|
|
|
for (size_t i = 0; i < SDL_arraysize(fadebars); i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
fadebars[i] = 320 + int(fRandom() * 12) * 8;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
setfade(416);
|
|
|
|
fademode = FADE_FADING_IN;
|
|
|
|
break;
|
|
|
|
case FADE_FADING_IN:
|
|
|
|
fadeamount -= 24;
|
|
|
|
if (fadeamount <= 0)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
fademode = FADE_NONE;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2022-04-25 10:21:43 +02:00
|
|
|
break;
|
Enumify all fade modes
This removes the magic numbers previously used for controlling the fade
mode, which are really not readable at all unless you already know what
they mean.
0: FADE_NONE
1: FADE_FULLY_BLACK
2: FADE_START_FADEOUT
3: FADE_FADING_OUT
4: FADE_START_FADEIN
5: FADE_FADING_IN
There is also the macro FADEMODE_IS_FADING, which indicates when the
intention is to only check if the game is fading right now, which wasn't
clearly conveyed previously.
I also took the opportunity to clean up the style of any lines I
touched. This included rewriting if-else chains into case-switches,
turning one-liner if-then statements into proper blocks, fixing up
comments, and even commenting the `fademode == FADE_NONE` on the tower
spike checks (which, it was previously undocumented why that check was
there, but I think I know why it's there).
As for type safety, we already get some by transforming the variable
types into the enum. Assignment is prohibited without a cast. But,
apparently, comparison is perfectly legal and won't even give so much as
a warning. To work around this and make absolutely sure I made all
existing comparisons now use the enum, I temporarily changed it to be an
`enum class`, which is a C++11 feature that makes it so all comparisons
are illegal. Unfortunately, it scopes them in a namespace with the same
name as a class, so I had to temporarily define macros to make sure my
existing code worked. I also had to temporarily up the standard in
CMakeLists.txt to get it to compile. But after all that was done, I
found the rest of the places where a comparison to an integer was used,
and fixed them.
2022-04-25 09:57:47 +02:00
|
|
|
case FADE_NONE:
|
|
|
|
case FADE_FULLY_BLACK:
|
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-03-20 07:09:11 +01:00
|
|
|
void Graphics::setfade(const int amount)
|
|
|
|
{
|
|
|
|
fadeamount = amount;
|
|
|
|
oldfadeamount = amount;
|
|
|
|
}
|
|
|
|
|
2022-12-30 22:57:24 +01:00
|
|
|
void Graphics::drawmenu(int cr, int cg, int cb, enum Menu::MenuName menu)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2022-12-30 22:57:24 +01:00
|
|
|
/* The MenuName is only used for some special cases,
|
|
|
|
* like the levels list and the language screen. */
|
|
|
|
|
|
|
|
bool language_screen = menu == Menu::language && !loc::languagelist.empty();
|
|
|
|
unsigned int twocol_voptions;
|
|
|
|
if (language_screen)
|
|
|
|
{
|
|
|
|
size_t n_options = game.menuoptions.size();
|
|
|
|
twocol_voptions = n_options - (n_options/2);
|
|
|
|
}
|
|
|
|
|
Refactor menu creation code
Firstly, menu options are no longer ad-hoc objects, and are added by
using Game::option() (this is the biggest change). This removes the
vector Game::menuoptionsactive, and Game::menuoptions is now a vector of
MenuOption instead of std::string.
Secondly, the manual tracker variable of the amount of menu options,
Game::nummenuoptions, has been removed, in favor of using vectors
properly and using Game::menuoptions::size().
As a result, a lot of copy-pasted code has been removed from
Game::createmenu(), mostly due to having to have different versions of
menus depending on whether or not we have certain defines, or having an
mmmmmm.vvv file inside the VVVVVV directory. In the old days, you
couldn't just add or remove a menu option conveniently, you had to
shuffle around the position of every other menu option too, which
resulted in lots of copy-pasted code. But now this copy-pasted code has
been de-duplicated, at least in Game::createmenu().
2020-04-15 06:50:17 +02:00
|
|
|
for (size_t i = 0; i < game.menuoptions.size(); i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-07-04 23:53:05 +02:00
|
|
|
MenuOption& opt = game.menuoptions[i];
|
|
|
|
|
|
|
|
int fr, fg, fb;
|
|
|
|
if (opt.active)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-07-04 23:53:05 +02:00
|
|
|
// Color it normally
|
|
|
|
fr = cr;
|
|
|
|
fg = cg;
|
|
|
|
fb = cb;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2020-07-04 23:53:05 +02:00
|
|
|
// Color it gray
|
|
|
|
fr = 128;
|
|
|
|
fg = 128;
|
|
|
|
fb = 128;
|
|
|
|
}
|
|
|
|
|
2022-12-30 22:57:24 +01:00
|
|
|
int x, y;
|
|
|
|
if (language_screen)
|
|
|
|
{
|
2023-01-15 04:06:31 +01:00
|
|
|
int name_len = font::len(opt.print_flags, opt.text);
|
2022-12-30 22:57:24 +01:00
|
|
|
x = (i < twocol_voptions ? 80 : 240) - name_len/2;
|
|
|
|
y = 36 + (i % twocol_voptions)*12;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
x = i*game.menuspacing + game.menuxoff;
|
|
|
|
y = 140 + i*12 + game.menuyoff;
|
|
|
|
}
|
2020-07-04 23:53:05 +02:00
|
|
|
|
2021-08-18 18:26:14 +02:00
|
|
|
#ifndef NO_CUSTOM_LEVELS
|
2022-12-30 22:57:24 +01:00
|
|
|
if (menu == Menu::levellist)
|
2020-07-04 23:53:05 +02:00
|
|
|
{
|
2021-08-18 18:17:41 +02:00
|
|
|
size_t separator;
|
2021-02-21 00:40:11 +01:00
|
|
|
if (cl.ListOfMetaData.size() > 8)
|
2021-08-18 18:17:41 +02:00
|
|
|
{
|
|
|
|
separator = 3;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
separator = 1;
|
|
|
|
}
|
|
|
|
if (game.menuoptions.size() - i <= separator)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-07-04 23:53:05 +02:00
|
|
|
// We're on "next page", "previous page", or "return to menu". Draw them separated by a bit
|
|
|
|
y += 8;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2020-07-04 23:53:05 +02:00
|
|
|
// Get out of the way of the level descriptions
|
|
|
|
y += 4;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
2021-08-18 18:26:14 +02:00
|
|
|
#endif
|
2022-12-24 04:16:56 +01:00
|
|
|
if (menu == Menu::translator_options_cutscenetest)
|
|
|
|
{
|
|
|
|
size_t separator = 4;
|
|
|
|
if (game.menuoptions.size() - i <= separator)
|
|
|
|
{
|
|
|
|
y += 4;
|
|
|
|
}
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2021-03-07 03:14:44 +01:00
|
|
|
char buffer[MENU_TEXT_BYTES];
|
2021-04-12 02:43:17 +02:00
|
|
|
if ((int) i == game.currentmenuoption && game.slidermode == SLIDER_NONE)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2022-12-30 22:57:24 +01:00
|
|
|
std::string opt_text;
|
2020-07-04 23:53:05 +02:00
|
|
|
if (opt.active)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-07-04 23:53:05 +02:00
|
|
|
// Uppercase the text
|
2022-12-30 22:57:24 +01:00
|
|
|
opt_text = loc::toupper(opt.text);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2022-12-30 22:57:24 +01:00
|
|
|
else
|
|
|
|
{
|
|
|
|
opt_text = loc::remove_toupper_escape_chars(opt.text);
|
|
|
|
}
|
|
|
|
|
|
|
|
vformat_buf(buffer, sizeof(buffer), loc::get_langmeta()->menu_select.c_str(), "label:str", opt_text.c_str());
|
2020-07-04 23:53:05 +02:00
|
|
|
|
|
|
|
// Account for brackets
|
2023-03-05 00:32:58 +01:00
|
|
|
x -= (font::len(opt.print_flags, buffer)-font::len(opt.print_flags, opt_text.c_str()))/2;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2022-12-30 22:57:24 +01:00
|
|
|
SDL_strlcpy(buffer, loc::remove_toupper_escape_chars(opt.text).c_str(), sizeof(buffer));
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-07-04 23:53:05 +02:00
|
|
|
|
2023-01-15 04:06:31 +01:00
|
|
|
font::print(opt.print_flags, x, y, buffer, fr, fg, fb);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-09-04 00:34:45 +02:00
|
|
|
void Graphics::drawcoloredtile(
|
2023-01-07 19:28:07 +01:00
|
|
|
const int x, const int y,
|
2021-09-04 00:34:45 +02:00
|
|
|
const int t,
|
2023-01-07 19:28:07 +01:00
|
|
|
const int r, const int g, const int b
|
2021-09-04 00:34:45 +02:00
|
|
|
) {
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_tiles_white, t, x, y, tiles_rect.w, tiles_rect.h, r, g, b);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2023-01-29 08:32:14 +01:00
|
|
|
bool Graphics::Hitest(SDL_Surface* surface1, SDL_Point p1, SDL_Surface* surface2, SDL_Point p2)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
|
|
|
|
//find rectangle where they intersect:
|
|
|
|
|
|
|
|
int r1_left = p1.x;
|
|
|
|
int r1_right = r1_left + surface1->w;
|
|
|
|
int r2_left = p2.x;
|
|
|
|
int r2_right = r2_left + surface2->w;
|
|
|
|
|
|
|
|
int r1_bottom = p1.y;
|
|
|
|
int r1_top = p1.y + surface1->h;
|
|
|
|
int r2_bottom = p2.y;
|
|
|
|
int r2_top = p2.y + surface2->h;
|
|
|
|
|
2020-08-04 09:55:18 +02:00
|
|
|
SDL_Rect rect1 = {p1.x, p1.y, surface1->w, surface1->h};
|
|
|
|
SDL_Rect rect2 = {p2.x, p2.y, surface2->w, surface2->h};
|
|
|
|
bool intersection = help.intersects(rect1, rect2);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
if(intersection)
|
|
|
|
{
|
Remove `VVV_min/max` in favor of `SDL_min/max`
VVV_min/max are functions that only operate on ints, and SDL_min/max are
macros that operate on any type but double-evaluate everything.
I know I more-or-less said earlier that SDL_min/max were dumb but I've
changed my mind and think it's better to use them, taking care to make
sure you don't double-evaluate, rather than trying to generate your own
litany of functions with either your own hand-rolled generation macros,
C++ templates, C11 generics, or GCC extensions (that last one you'd
technically use in a macro but it doesn't really matter), all of which
have more downsides than just not double-evaluating.
And the upside of not double-evaluating is that you're disencouraged
from having really complicated single-line min/max expressions and
encouraged to precompute the values beforehand anyway so the final
min/max is more readable. And furthermore you'll notice when you
yourself end up doing double-evaluations anyway. I removed a couple
instances of Graphics::len() being double-evaluated in this commit (as
well as cleaned up some other min/max-using code). Although the only
downside to those double-evaluations was unnecessary computation,
rather than checking the wrong result or having multiple side effects,
thankfully, it's still good to minimize double-evaluations where
possible.
2021-12-23 01:43:31 +01:00
|
|
|
int r3_left = SDL_max(r1_left, r2_left);
|
|
|
|
int r3_top = SDL_min(r1_top, r2_top);
|
|
|
|
int r3_right = SDL_min(r1_right, r2_right);
|
|
|
|
int r3_bottom= SDL_max(r1_bottom, r2_bottom);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
//for every pixel inside rectangle
|
|
|
|
for(int x = r3_left; x < r3_right; x++)
|
|
|
|
{
|
|
|
|
for(int y = r3_bottom; y < r3_top; y++)
|
|
|
|
{
|
2023-01-02 01:36:43 +01:00
|
|
|
const SDL_Color pixel1 = ReadPixel(surface1, x - p1.x, y - p1.y);
|
|
|
|
const SDL_Color pixel2 = ReadPixel(surface2, x - p2.x, y - p2.y);
|
2021-10-07 08:18:58 +02:00
|
|
|
/* INTENTIONAL BUG! In previous versions, the game mistakenly
|
|
|
|
* checked the red channel, not the alpha channel.
|
|
|
|
* We preserve it here because some people abuse this. */
|
2023-01-02 01:36:43 +01:00
|
|
|
if (pixel1.r != 0 && pixel2.r != 0)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-08-04 09:56:45 +02:00
|
|
|
return false;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
}
|
|
|
|
|
2020-03-31 21:26:11 +02:00
|
|
|
void Graphics::drawgravityline( int t )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-11-01 05:23:59 +01:00
|
|
|
if (!INBOUNDS_VEC(t, obj.entities))
|
|
|
|
{
|
|
|
|
WHINE_ONCE("drawgravityline() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-11-08 02:29:06 +01:00
|
|
|
if (obj.entities[t].life == 0)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
switch(linestate)
|
|
|
|
{
|
|
|
|
case 0:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(200-20, 200-20, 200-20));
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 1:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(245-30, 245-30, 225-30));
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 2:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(225-30, 245-30, 245-30));
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 3:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(200-20, 200-20, 164-10));
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 4:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(196-20, 255-30, 224-20));
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 5:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(196-20, 235-30, 205-20));
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 6:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(164-10, 164-10, 164-10));
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 7:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(205-20, 245-30, 225-30));
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 8:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(225-30, 255-30, 205-20));
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 9:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(245-30, 245-30, 245-30));
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&line_rect, getRGB(96, 96, 96));
|
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 Graphics::drawtrophytext(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
Implement first font::print function, fix most fading of colored glyphs
There has always been a mess of different print functions that all had
slightly different specifics and called each other:
Print(x, y, text, r, g, b, cen)
nothing special here, just does what the arguments say
PrintAlpha(x, y, text, r, g, b, a, cen)
just Print but with an alpha argument
PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth)
added for wordwrapping, heavily used now
bprint(x, y, text, r, g, b, cen)
prints an outline, then just PrintAlpha
bprintalpha(x, y, text, r, g, b, a, cen)
just bprint but with an alpha argument
bigprint(x, y, text, r, g, b, cen, sc)
nothing special here, just does what the arguments say
bigbprint(x, y, text, r, g, b, cen, sc)
prints an outline, then just bigprint
bigrprint(x, y, text, r, g, b, cen, sc)
right-aligns text, unless cen is given in which case it just
centers text like other functions already do?
bigbrprint(x, y, text, r, g, b, cen, sc)
prints an outline, then just bigrprint
We need even more specifics with the new font system: we need to be
able to specify whether CJK characters should be vertically centered or
stick out on the top/bottom, and we sometimes need to pass in
brightness variables for colored glyphs. And text printing functions
now fit better in Font.cpp anyway. So there's now a big overhaul of
print functions: all these functions will be replaced by font::print
and font::print_wrap (the former of which now exists). These take flags
as their first argument, which can be 0 for a basic left-aligned print,
PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead
of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling,
and these can be combined with |.
Some text, for example [Press ESC to return to editor], fades in/out
using the alpha value, which is passed to the print function. In some
other places (like Press ENTER to teleport, textboxes, trophy text...)
text can fade in or out by direct changes to the RGB values. This means
regular color-adjusted white text can change color, but colored button
glyphs can't, since there's no way to know in the print system what the
maximum RGB values of a specific textbox are supposed to be, so the
only thing it can do is draw the button glyphs at full brightness,
which looks bad. Therefore, you can now also pass in the brightness
value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
|
|
|
int brightness;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
if (obj.trophytext < 15)
|
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
const int usethismult = lerp(obj.oldtrophytext, obj.trophytext);
|
Implement first font::print function, fix most fading of colored glyphs
There has always been a mess of different print functions that all had
slightly different specifics and called each other:
Print(x, y, text, r, g, b, cen)
nothing special here, just does what the arguments say
PrintAlpha(x, y, text, r, g, b, a, cen)
just Print but with an alpha argument
PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth)
added for wordwrapping, heavily used now
bprint(x, y, text, r, g, b, cen)
prints an outline, then just PrintAlpha
bprintalpha(x, y, text, r, g, b, a, cen)
just bprint but with an alpha argument
bigprint(x, y, text, r, g, b, cen, sc)
nothing special here, just does what the arguments say
bigbprint(x, y, text, r, g, b, cen, sc)
prints an outline, then just bigprint
bigrprint(x, y, text, r, g, b, cen, sc)
right-aligns text, unless cen is given in which case it just
centers text like other functions already do?
bigbrprint(x, y, text, r, g, b, cen, sc)
prints an outline, then just bigrprint
We need even more specifics with the new font system: we need to be
able to specify whether CJK characters should be vertically centered or
stick out on the top/bottom, and we sometimes need to pass in
brightness variables for colored glyphs. And text printing functions
now fit better in Font.cpp anyway. So there's now a big overhaul of
print functions: all these functions will be replaced by font::print
and font::print_wrap (the former of which now exists). These take flags
as their first argument, which can be 0 for a basic left-aligned print,
PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead
of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling,
and these can be combined with |.
Some text, for example [Press ESC to return to editor], fades in/out
using the alpha value, which is passed to the print function. In some
other places (like Press ENTER to teleport, textboxes, trophy text...)
text can fade in or out by direct changes to the RGB values. This means
regular color-adjusted white text can change color, but colored button
glyphs can't, since there's no way to know in the print system what the
maximum RGB values of a specific textbox are supposed to be, so the
only thing it can do is draw the button glyphs at full brightness,
which looks bad. Therefore, you can now also pass in the brightness
value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
|
|
|
brightness = (usethismult/15.0)*255;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Implement first font::print function, fix most fading of colored glyphs
There has always been a mess of different print functions that all had
slightly different specifics and called each other:
Print(x, y, text, r, g, b, cen)
nothing special here, just does what the arguments say
PrintAlpha(x, y, text, r, g, b, a, cen)
just Print but with an alpha argument
PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth)
added for wordwrapping, heavily used now
bprint(x, y, text, r, g, b, cen)
prints an outline, then just PrintAlpha
bprintalpha(x, y, text, r, g, b, a, cen)
just bprint but with an alpha argument
bigprint(x, y, text, r, g, b, cen, sc)
nothing special here, just does what the arguments say
bigbprint(x, y, text, r, g, b, cen, sc)
prints an outline, then just bigprint
bigrprint(x, y, text, r, g, b, cen, sc)
right-aligns text, unless cen is given in which case it just
centers text like other functions already do?
bigbrprint(x, y, text, r, g, b, cen, sc)
prints an outline, then just bigrprint
We need even more specifics with the new font system: we need to be
able to specify whether CJK characters should be vertically centered or
stick out on the top/bottom, and we sometimes need to pass in
brightness variables for colored glyphs. And text printing functions
now fit better in Font.cpp anyway. So there's now a big overhaul of
print functions: all these functions will be replaced by font::print
and font::print_wrap (the former of which now exists). These take flags
as their first argument, which can be 0 for a basic left-aligned print,
PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead
of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling,
and these can be combined with |.
Some text, for example [Press ESC to return to editor], fades in/out
using the alpha value, which is passed to the print function. In some
other places (like Press ENTER to teleport, textboxes, trophy text...)
text can fade in or out by direct changes to the RGB values. This means
regular color-adjusted white text can change color, but colored button
glyphs can't, since there's no way to know in the print system what the
maximum RGB values of a specific textbox are supposed to be, so the
only thing it can do is draw the button glyphs at full brightness,
which looks bad. Therefore, you can now also pass in the brightness
value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
|
|
|
brightness = 255;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2022-12-30 23:39:12 +01:00
|
|
|
|
|
|
|
/* These were originally all at the top of the screen, but might be too tight for localization.
|
|
|
|
* It probably makes sense to make them all have a top text now, but for now this is probably fine.
|
|
|
|
* Look at the Steam achievements, they have pretty logical titles that should probably be used. */
|
|
|
|
const char* top_text = NULL;
|
|
|
|
const char* bottom_text = NULL;
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
switch(obj.trophytype)
|
|
|
|
{
|
|
|
|
case 1:
|
2022-12-30 23:39:12 +01:00
|
|
|
top_text = loc::gettext("SPACE STATION 1 MASTERED");
|
|
|
|
bottom_text = loc::gettext("Obtain a V Rank in this Time Trial");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 2:
|
2022-12-30 23:39:12 +01:00
|
|
|
top_text = loc::gettext("LABORATORY MASTERED");
|
|
|
|
bottom_text = loc::gettext("Obtain a V Rank in this Time Trial");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 3:
|
2022-12-30 23:39:12 +01:00
|
|
|
top_text = loc::gettext("THE TOWER MASTERED");
|
|
|
|
bottom_text = loc::gettext("Obtain a V Rank in this Time Trial");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 4:
|
2022-12-30 23:39:12 +01:00
|
|
|
top_text = loc::gettext("SPACE STATION 2 MASTERED");
|
|
|
|
bottom_text = loc::gettext("Obtain a V Rank in this Time Trial");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 5:
|
2022-12-30 23:39:12 +01:00
|
|
|
top_text = loc::gettext("WARP ZONE MASTERED");
|
|
|
|
bottom_text = loc::gettext("Obtain a V Rank in this Time Trial");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 6:
|
2022-12-30 23:39:12 +01:00
|
|
|
top_text = loc::gettext("FINAL LEVEL MASTERED");
|
|
|
|
bottom_text = loc::gettext("Obtain a V Rank in this Time Trial");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 7:
|
2022-12-30 23:39:12 +01:00
|
|
|
top_text = loc::gettext("GAME COMPLETE");
|
|
|
|
bottom_text = loc::gettext("Complete the game");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 8:
|
2022-12-30 23:39:12 +01:00
|
|
|
top_text = loc::gettext("FLIP MODE COMPLETE");
|
|
|
|
bottom_text = loc::gettext("Complete the game in flip mode");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 9:
|
2022-12-30 23:39:12 +01:00
|
|
|
bottom_text = loc::gettext("Win with less than 50 deaths");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 10:
|
2022-12-30 23:39:12 +01:00
|
|
|
bottom_text = loc::gettext("Win with less than 100 deaths");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 11:
|
2022-12-30 23:39:12 +01:00
|
|
|
bottom_text = loc::gettext("Win with less than 250 deaths");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 12:
|
2022-12-30 23:39:12 +01:00
|
|
|
bottom_text = loc::gettext("Win with less than 500 deaths");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 13:
|
2022-12-30 23:39:12 +01:00
|
|
|
bottom_text = loc::gettext("Last 5 seconds on the Super Gravitron");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 14:
|
2022-12-30 23:39:12 +01:00
|
|
|
bottom_text = loc::gettext("Last 10 seconds on the Super Gravitron");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 15:
|
2022-12-30 23:39:12 +01:00
|
|
|
bottom_text = loc::gettext("Last 15 seconds on the Super Gravitron");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 16:
|
2022-12-30 23:39:12 +01:00
|
|
|
bottom_text = loc::gettext("Last 20 seconds on the Super Gravitron");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 17:
|
2022-12-30 23:39:12 +01:00
|
|
|
bottom_text = loc::gettext("Last 30 seconds on the Super Gravitron");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 18:
|
2022-12-30 23:39:12 +01:00
|
|
|
bottom_text = loc::gettext("Last 1 minute on the Super Gravitron");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
case 20:
|
2022-12-30 23:39:12 +01:00
|
|
|
top_text = loc::gettext("MASTER OF THE UNIVERSE");
|
|
|
|
bottom_text = loc::gettext("Complete the game in no death mode");
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
|
|
|
}
|
2022-12-30 23:39:12 +01:00
|
|
|
|
|
|
|
short lines;
|
|
|
|
if (top_text != NULL)
|
|
|
|
{
|
2023-01-21 02:31:44 +01:00
|
|
|
font::string_wordwrap(0, top_text, 304, &lines);
|
Replace PR_COLORGLYPH_BRI(a) and PR_ALPHA(a) with PR_BRIGHTNESS(a)
There used to be two ways of fading in/out text in VVVVVV:
- Local code that modifies the R, G and B values of the text
- Keeping the RGB values the same and using the alpha channel
The latter approach is only used once, for [Press ENTER to return to
editor]. The former approach causes problems with colored (button)
glyphs: there's no way for the print function to tell from the RGB
values whether a color is "full Viridian-cyan" or "Viridian-cyan faded
out 50%", so I added the flag PR_COLORGLYPH_BRI(value) to tell the
print function that the color brightness is reduced to match the
brightness of colored glyphs to the brightness of the rest of the text.
However, there were already plans to make the single use of alpha
consistent with the rest of the game and the style, so PR_ALPHA(value)
could be removed, as well as the bit signifying whether the brightness
or alpha value is used. For the editor text, I simply copied the "Press
{button} to teleport" behavior of hiding the text completely if it
becomes darker than 100/255.
Another simplification is to make the print function handle not just
the brightness of the color glyphs while local code handled the
brightness of the normal text color, but to make the print function
handle both. That way, the callsite can simply pass in the full colors
and the brightness flag, and the flag name can be made a lot simpler as
well: PR_BRIGHTNESS(value).
2023-01-31 02:22:43 +01:00
|
|
|
font::print_wrap(PR_CEN | PR_BRIGHTNESS(brightness) | PR_BOR, -1, 11-(lines-1)*5, top_text, 196, 196, 255 - help.glow);
|
2022-12-30 23:39:12 +01:00
|
|
|
}
|
|
|
|
if (bottom_text != NULL)
|
|
|
|
{
|
2023-01-21 02:31:44 +01:00
|
|
|
font::string_wordwrap(0, bottom_text, 304, &lines);
|
Replace PR_COLORGLYPH_BRI(a) and PR_ALPHA(a) with PR_BRIGHTNESS(a)
There used to be two ways of fading in/out text in VVVVVV:
- Local code that modifies the R, G and B values of the text
- Keeping the RGB values the same and using the alpha channel
The latter approach is only used once, for [Press ENTER to return to
editor]. The former approach causes problems with colored (button)
glyphs: there's no way for the print function to tell from the RGB
values whether a color is "full Viridian-cyan" or "Viridian-cyan faded
out 50%", so I added the flag PR_COLORGLYPH_BRI(value) to tell the
print function that the color brightness is reduced to match the
brightness of colored glyphs to the brightness of the rest of the text.
However, there were already plans to make the single use of alpha
consistent with the rest of the game and the style, so PR_ALPHA(value)
could be removed, as well as the bit signifying whether the brightness
or alpha value is used. For the editor text, I simply copied the "Press
{button} to teleport" behavior of hiding the text completely if it
becomes darker than 100/255.
Another simplification is to make the print function handle not just
the brightness of the color glyphs while local code handled the
brightness of the normal text color, but to make the print function
handle both. That way, the callsite can simply pass in the full colors
and the brightness flag, and the flag name can be made a lot simpler as
well: PR_BRIGHTNESS(value).
2023-01-31 02:22:43 +01:00
|
|
|
font::print_wrap(PR_CEN | PR_BRIGHTNESS(brightness) | PR_BOR, -1, 221-(lines-1)*5, bottom_text, 196, 196, 255 - help.glow);
|
2022-12-30 23:39:12 +01:00
|
|
|
}
|
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 Graphics::drawentities(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-11-01 05:38:15 +01:00
|
|
|
const int yoff = map.towermode ? lerp(map.oldypos, map.ypos) : 0;
|
|
|
|
|
Fix crewmates being drawn behind other entities
This fixes the draw order by drawing all other entities first, before
then drawing all humanoids[1] after, including the player afterwards.
This is actually a regression fix from #191. When I was testing this, I
was thinking about where get a crewmate in front of another entity in
the main game, other than the checkpoints in Intermission 1. And then I
thought about the teleporters, because I remember the pre-Deep Space
cutscene in Dimension Open looking funny because Vita ended up being
behind the teleporter. (Actually, a lot of the cutscenes of Dimension
Open look funny because of crewmates standing behind terminals.)
So then I tried to get crewmates in front of teleporters. It actually
turns out that you can't do it for most of them... except for Verdigris.
And then that's what I realized why there was an oddity in WarpClass.cpp
when I was removing the `active` system from the game - for some reason,
the game put a hole in `obj.entities` between the teleporter and the
player when loading the room Murdering Twinmaker. In a violation of
Chesterton's Fence (the principle that you should understand something
before removing it), I shrugged it off and decided "there's no way to
support having holes with my new system, and having holes is probably
bad anyway, so I'm going to remove this and move on". The fact that
there wasn't any comments clarifying the mysterious code didn't help
(but, this *was* 2.2 code after all; have you *seen* 2.2 code?!).
And it turns out that this maneuver was done so Verdigris would fill
that hole when he got created, and Verdigris being first before the
teleporter would mean he would be drawn in front of the teleporter,
instead of being behind it. So ever since
b1b1474b7bbc3ceddea24f689a7ddb050cfe4490 got merged, there has actually
been a regression from 2.2 where Verdigris got drawn behind the
teleporter in Murdering Twinmaker, instead of properly being in front of
it like in 2.2 and previous.
This patch fixes that regression, but it actually properly fixes it
instead of hacking around with the `active` system.
Closes #426.
[1]: I'm going to go on a rant here, so hear me out. It's not explicitly
stated that the characters in VVVVVV are human. So, given this
information, what do we call them? Well, the VVVVVV community (at least
the custom levels one, I don't think the speedrunning community does
this or is preoccupied with lore in the first place) decided to call
them "villis", because of the roomname "The Villi People" - which is
only one blunder in a series of awful headcanons based off of the
assumption that the intent of Bennett Foddy (who named the roomnames)
was to decree some sort of lore to the game. Another one being
"Verdigris can't flip" because of "Green Dudes Can't Flip". Then an OC
(original character) got named based off of "The Voon Show" too. And so
on and so forth.
2020-11-01 07:23:40 +01:00
|
|
|
if (!map.custommode)
|
2020-11-01 05:38:15 +01:00
|
|
|
{
|
Fix crewmates being drawn behind other entities
This fixes the draw order by drawing all other entities first, before
then drawing all humanoids[1] after, including the player afterwards.
This is actually a regression fix from #191. When I was testing this, I
was thinking about where get a crewmate in front of another entity in
the main game, other than the checkpoints in Intermission 1. And then I
thought about the teleporters, because I remember the pre-Deep Space
cutscene in Dimension Open looking funny because Vita ended up being
behind the teleporter. (Actually, a lot of the cutscenes of Dimension
Open look funny because of crewmates standing behind terminals.)
So then I tried to get crewmates in front of teleporters. It actually
turns out that you can't do it for most of them... except for Verdigris.
And then that's what I realized why there was an oddity in WarpClass.cpp
when I was removing the `active` system from the game - for some reason,
the game put a hole in `obj.entities` between the teleporter and the
player when loading the room Murdering Twinmaker. In a violation of
Chesterton's Fence (the principle that you should understand something
before removing it), I shrugged it off and decided "there's no way to
support having holes with my new system, and having holes is probably
bad anyway, so I'm going to remove this and move on". The fact that
there wasn't any comments clarifying the mysterious code didn't help
(but, this *was* 2.2 code after all; have you *seen* 2.2 code?!).
And it turns out that this maneuver was done so Verdigris would fill
that hole when he got created, and Verdigris being first before the
teleporter would mean he would be drawn in front of the teleporter,
instead of being behind it. So ever since
b1b1474b7bbc3ceddea24f689a7ddb050cfe4490 got merged, there has actually
been a regression from 2.2 where Verdigris got drawn behind the
teleporter in Murdering Twinmaker, instead of properly being in front of
it like in 2.2 and previous.
This patch fixes that regression, but it actually properly fixes it
instead of hacking around with the `active` system.
Closes #426.
[1]: I'm going to go on a rant here, so hear me out. It's not explicitly
stated that the characters in VVVVVV are human. So, given this
information, what do we call them? Well, the VVVVVV community (at least
the custom levels one, I don't think the speedrunning community does
this or is preoccupied with lore in the first place) decided to call
them "villis", because of the roomname "The Villi People" - which is
only one blunder in a series of awful headcanons based off of the
assumption that the intent of Bennett Foddy (who named the roomnames)
was to decree some sort of lore to the game. Another one being
"Verdigris can't flip" because of "Green Dudes Can't Flip". Then an OC
(original character) got named based off of "The Voon Show" too. And so
on and so forth.
2020-11-01 07:23:40 +01:00
|
|
|
for (int i = obj.entities.size() - 1; i >= 0; i--)
|
|
|
|
{
|
|
|
|
if (!obj.entities[i].ishumanoid())
|
|
|
|
{
|
|
|
|
drawentity(i, yoff);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int i = obj.entities.size() - 1; i >= 0; i--)
|
|
|
|
{
|
|
|
|
if (obj.entities[i].ishumanoid())
|
|
|
|
{
|
|
|
|
drawentity(i, yoff);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
for (int i = obj.entities.size() - 1; i >= 0; i--)
|
|
|
|
{
|
|
|
|
drawentity(i, yoff);
|
|
|
|
}
|
2020-11-01 05:38:15 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::drawentity(const int i, const int yoff)
|
|
|
|
{
|
|
|
|
if (!INBOUNDS_VEC(i, obj.entities))
|
|
|
|
{
|
|
|
|
WHINE_ONCE("drawentity() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-11-01 05:39:19 +01:00
|
|
|
if (obj.entities[i].invis)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
2020-11-01 05:38:15 +01:00
|
|
|
|
2023-01-29 08:32:14 +01:00
|
|
|
SDL_Point tpoint;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
SDL_Rect drawRect;
|
|
|
|
|
2020-06-30 00:27:23 +02:00
|
|
|
#if !defined(NO_CUSTOM_LEVELS)
|
|
|
|
// Special case for gray Warp Zone tileset!
|
2021-02-21 00:45:48 +01:00
|
|
|
const RoomProperty* const room = cl.getroomprop(game.roomx - 100, game.roomy - 100);
|
2021-03-24 19:59:36 +01:00
|
|
|
const bool custom_gray = room->tileset == 3 && room->tilecol == 6;
|
2020-06-30 00:27:23 +02:00
|
|
|
#else
|
2020-10-20 08:57:23 +02:00
|
|
|
const bool custom_gray = false;
|
2020-06-30 00:27:23 +02:00
|
|
|
#endif
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
SDL_Texture* sprites = flipmode ? grphx.im_flipsprites : grphx.im_sprites;
|
|
|
|
SDL_Texture* tiles = (map.custommode && !map.finalmode) ? grphx.im_entcolours : grphx.im_tiles;
|
|
|
|
SDL_Texture* tiles_tint = (map.custommode && !map.finalmode) ? grphx.im_entcolours_tint : grphx.im_tiles_tint;
|
2020-04-26 04:47:09 +02:00
|
|
|
|
2020-11-01 05:39:19 +01:00
|
|
|
const int xp = lerp(obj.entities[i].lerpoldxp, obj.entities[i].xp);
|
|
|
|
const int yp = lerp(obj.entities[i].lerpoldyp, obj.entities[i].yp);
|
2020-04-29 01:02:55 +02:00
|
|
|
|
2020-11-01 05:39:19 +01:00
|
|
|
switch (obj.entities[i].size)
|
|
|
|
{
|
|
|
|
case 0:
|
|
|
|
{
|
|
|
|
// Sprites
|
|
|
|
tpoint.x = xp;
|
|
|
|
tpoint.y = yp - yoff;
|
2023-01-02 05:16:08 +01:00
|
|
|
const SDL_Color ct = obj.entities[i].realcol;
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
drawRect = sprites_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe, drawRect.x, drawRect.y, 32, 32, ct);
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
//screenwrapping!
|
2023-01-29 08:32:14 +01:00
|
|
|
SDL_Point wrappedPoint;
|
2020-11-01 05:39:19 +01:00
|
|
|
bool wrapX = false;
|
|
|
|
bool wrapY = false;
|
|
|
|
|
|
|
|
wrappedPoint.x = tpoint.x;
|
|
|
|
if (tpoint.x < 0)
|
2020-07-29 18:17:28 +02:00
|
|
|
{
|
2020-11-01 05:39:19 +01:00
|
|
|
wrapX = true;
|
|
|
|
wrappedPoint.x += 320;
|
|
|
|
}
|
2021-12-21 05:13:36 +01:00
|
|
|
else if (tpoint.x > 288)
|
2020-11-01 05:39:19 +01:00
|
|
|
{
|
|
|
|
wrapX = true;
|
|
|
|
wrappedPoint.x -= 320;
|
|
|
|
}
|
|
|
|
|
|
|
|
wrappedPoint.y = tpoint.y;
|
2021-04-14 03:26:06 +02:00
|
|
|
if (tpoint.y < 8)
|
2020-11-01 05:39:19 +01:00
|
|
|
{
|
|
|
|
wrapY = true;
|
2021-04-14 03:21:21 +02:00
|
|
|
wrappedPoint.y += 232;
|
2020-11-01 05:39:19 +01:00
|
|
|
}
|
2021-12-21 05:13:36 +01:00
|
|
|
else if (tpoint.y > 200)
|
2020-11-01 05:39:19 +01:00
|
|
|
{
|
|
|
|
wrapY = true;
|
2021-04-14 03:21:21 +02:00
|
|
|
wrappedPoint.y -= 232;
|
2020-11-01 05:39:19 +01:00
|
|
|
}
|
2020-04-26 20:13:47 +02:00
|
|
|
|
2020-11-01 05:39:19 +01:00
|
|
|
const bool isInWrappingAreaOfTower = map.towermode && !map.minitowermode && map.ypos >= 500 && map.ypos <= 5000;
|
|
|
|
if (wrapX && (map.warpx || isInWrappingAreaOfTower))
|
|
|
|
{
|
2020-04-26 20:13:47 +02:00
|
|
|
drawRect = sprites_rect;
|
2020-11-01 05:39:19 +01:00
|
|
|
drawRect.x += wrappedPoint.x;
|
2020-04-26 20:13:47 +02:00
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe, drawRect.x, drawRect.y, 32, 32, ct);
|
2020-07-29 18:17:28 +02:00
|
|
|
}
|
2020-11-01 05:39:19 +01:00
|
|
|
if (wrapY && map.warpy)
|
|
|
|
{
|
|
|
|
drawRect = sprites_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += wrappedPoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe, drawRect.x, drawRect.y, 32, 32, ct);
|
2020-11-01 05:39:19 +01:00
|
|
|
}
|
|
|
|
if (wrapX && wrapY && map.warpx && map.warpy)
|
|
|
|
{
|
|
|
|
drawRect = sprites_rect;
|
|
|
|
drawRect.x += wrappedPoint.x;
|
|
|
|
drawRect.y += wrappedPoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe, drawRect.x, drawRect.y, 32, 32, ct);
|
2020-11-01 05:39:19 +01:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case 1:
|
|
|
|
// Tiles
|
|
|
|
tpoint.x = xp;
|
|
|
|
tpoint.y = yp - yoff;
|
|
|
|
drawRect = tiles_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(grphx.im_tiles, obj.entities[i].drawframe, drawRect.x, drawRect.y, 8, 8);
|
2020-11-01 05:39:19 +01:00
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
case 8:
|
|
|
|
{
|
|
|
|
// Special: Moving platform, 4 tiles or 8 tiles
|
2023-01-07 19:28:07 +01:00
|
|
|
|
2020-11-01 05:39:19 +01:00
|
|
|
tpoint.x = xp;
|
|
|
|
tpoint.y = yp - yoff;
|
|
|
|
int thiswidth = 4;
|
|
|
|
if (obj.entities[i].size == 8)
|
|
|
|
{
|
|
|
|
thiswidth = 8;
|
|
|
|
}
|
|
|
|
for (int ii = 0; ii < thiswidth; ii++)
|
|
|
|
{
|
2020-04-26 20:13:47 +02:00
|
|
|
drawRect = tiles_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2020-11-01 05:39:19 +01:00
|
|
|
drawRect.x += 8 * ii;
|
|
|
|
if (custom_gray)
|
2020-06-14 03:35:12 +02:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(tiles_tint, obj.entities[i].drawframe, drawRect.x, drawRect.y, 8, 8);
|
2020-06-14 03:35:12 +02:00
|
|
|
}
|
2020-11-01 05:39:19 +01:00
|
|
|
else
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(tiles, obj.entities[i].drawframe, drawRect.x, drawRect.y, 8, 8);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-04-26 20:13:47 +02:00
|
|
|
}
|
2020-11-01 05:39:19 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case 3: // Big chunky pixels!
|
|
|
|
prect.x = xp;
|
|
|
|
prect.y = yp - yoff;
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&prect, obj.entities[i].realcol);
|
2020-11-01 05:39:19 +01:00
|
|
|
break;
|
|
|
|
case 4: // Small pickups
|
2023-01-07 19:28:07 +01:00
|
|
|
{
|
|
|
|
const SDL_Color color = obj.entities[i].realcol;
|
|
|
|
drawcoloredtile(xp, yp - yoff, obj.entities[i].tile, color.r, color.g, color.b);
|
2020-11-01 05:39:19 +01:00
|
|
|
break;
|
2023-01-07 19:28:07 +01:00
|
|
|
}
|
2020-11-01 05:39:19 +01:00
|
|
|
case 5: //Horizontal Line
|
|
|
|
{
|
|
|
|
int oldw = obj.entities[i].w;
|
|
|
|
if ((game.swngame == 3 || kludgeswnlinewidth) && obj.getlineat(84 - 32) == i)
|
2020-05-02 02:57:07 +02:00
|
|
|
{
|
2020-11-01 05:39:19 +01:00
|
|
|
oldw -= 24;
|
|
|
|
}
|
|
|
|
line_rect.x = xp;
|
|
|
|
line_rect.y = yp - yoff;
|
|
|
|
line_rect.w = lerp(oldw, obj.entities[i].w);
|
|
|
|
line_rect.h = 1;
|
|
|
|
drawgravityline(i);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case 6: //Vertical Line
|
|
|
|
line_rect.x = xp;
|
|
|
|
line_rect.y = yp - yoff;
|
|
|
|
line_rect.w = 1;
|
|
|
|
line_rect.h = obj.entities[i].h;
|
|
|
|
drawgravityline(i);
|
|
|
|
break;
|
|
|
|
case 7: //Teleporter
|
|
|
|
drawtele(xp, yp - yoff, obj.entities[i].drawframe, obj.entities[i].realcol);
|
|
|
|
break;
|
|
|
|
//case 8: // Special: Moving platform, 8 tiles
|
|
|
|
// Note: This code is in the 4-tile code
|
|
|
|
break;
|
|
|
|
case 9: // Really Big Sprite! (2x2)
|
2023-01-02 05:16:08 +01:00
|
|
|
{
|
|
|
|
const SDL_Color ct = obj.entities[i].realcol;
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
tpoint.x = xp;
|
|
|
|
tpoint.y = yp - yoff;
|
|
|
|
|
|
|
|
drawRect = sprites_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe, drawRect.x, drawRect.y, 32, 32, ct);
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
tpoint.x = xp+32;
|
|
|
|
tpoint.y = yp - yoff;
|
|
|
|
//
|
|
|
|
drawRect = sprites_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe + 1, drawRect.x, drawRect.y, 32, 32, ct);
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
tpoint.x = xp;
|
|
|
|
tpoint.y = yp+32 - yoff;
|
|
|
|
//
|
|
|
|
drawRect = sprites_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe + 12, drawRect.x, drawRect.y, 32, 32, ct);
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
tpoint.x = xp+32;
|
|
|
|
tpoint.y = yp+32 - yoff;
|
|
|
|
//
|
|
|
|
drawRect = sprites_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe + 13, drawRect.x, drawRect.y, 32, 32, ct);
|
2021-03-24 20:32:43 +01:00
|
|
|
break;
|
2023-01-02 05:16:08 +01:00
|
|
|
}
|
2021-03-24 20:32:43 +01:00
|
|
|
case 10: // 2x1 Sprite
|
2023-01-02 05:16:08 +01:00
|
|
|
{
|
|
|
|
const SDL_Color ct = obj.entities[i].realcol;
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
tpoint.x = xp;
|
|
|
|
tpoint.y = yp - yoff;
|
|
|
|
//
|
|
|
|
drawRect = sprites_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe, drawRect.x, drawRect.y, 32, 32, ct);
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
tpoint.x = xp+32;
|
|
|
|
tpoint.y = yp - yoff;
|
|
|
|
//
|
|
|
|
drawRect = sprites_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe + 1, drawRect.x, drawRect.y, 32, 32, ct);
|
2020-11-01 05:39:19 +01:00
|
|
|
break;
|
2023-01-02 05:16:08 +01:00
|
|
|
}
|
2020-11-01 05:39:19 +01:00
|
|
|
case 11: //The fucking elephant
|
2023-01-07 19:28:07 +01:00
|
|
|
drawimagecol(IMAGE_ELEPHANT, xp, yp - yoff, obj.entities[i].realcol);
|
2020-11-01 05:39:19 +01:00
|
|
|
break;
|
|
|
|
case 12: // Regular sprites that don't wrap
|
2023-01-02 05:16:08 +01:00
|
|
|
{
|
2020-11-01 05:39:19 +01:00
|
|
|
tpoint.x = xp;
|
|
|
|
tpoint.y = yp - yoff;
|
2023-01-02 05:16:08 +01:00
|
|
|
const SDL_Color ct = obj.entities[i].realcol;
|
2020-11-01 05:39:19 +01:00
|
|
|
//
|
|
|
|
drawRect = sprites_rect;
|
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(sprites, obj.entities[i].drawframe, drawRect.x, drawRect.y, 32, 32, ct);
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
//if we're outside the screen, we need to draw indicators
|
|
|
|
|
|
|
|
if (obj.entities[i].xp < -20 && obj.entities[i].vx > 0)
|
|
|
|
{
|
|
|
|
if (obj.entities[i].xp < -100)
|
2020-05-02 02:57:07 +02:00
|
|
|
{
|
2021-06-12 07:20:06 +02:00
|
|
|
tpoint.x = -5 + (int(( -xp) / 10));
|
2020-05-02 02:57:07 +02:00
|
|
|
}
|
2020-11-01 05:39:19 +01:00
|
|
|
else
|
2020-06-14 03:35:12 +02:00
|
|
|
{
|
2020-11-01 05:39:19 +01:00
|
|
|
tpoint.x = 5;
|
2020-06-14 03:35:12 +02:00
|
|
|
}
|
2020-04-26 20:13:47 +02:00
|
|
|
|
2020-11-01 05:39:19 +01:00
|
|
|
tpoint.y = tpoint.y+4;
|
2020-04-26 20:13:47 +02:00
|
|
|
|
|
|
|
|
2020-11-01 05:39:19 +01:00
|
|
|
drawRect = tiles_rect;
|
2020-04-26 20:13:47 +02:00
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(grphx.im_tiles_white, 1167, drawRect.x, drawRect.y, 8, 8, ct);
|
2020-04-26 20:13:47 +02:00
|
|
|
|
2020-11-01 05:39:19 +01:00
|
|
|
}
|
|
|
|
else if (obj.entities[i].xp > 340 && obj.entities[i].vx < 0)
|
|
|
|
{
|
|
|
|
if (obj.entities[i].xp > 420)
|
2020-06-14 03:35:12 +02:00
|
|
|
{
|
2021-06-12 07:20:06 +02:00
|
|
|
tpoint.x = 320 - (int(( xp-320) / 10));
|
2020-06-14 03:35:12 +02:00
|
|
|
}
|
2020-11-01 05:39:19 +01:00
|
|
|
else
|
2020-06-14 03:35:12 +02:00
|
|
|
{
|
2020-11-01 05:39:19 +01:00
|
|
|
tpoint.x = 310;
|
2020-06-14 03:35:12 +02:00
|
|
|
}
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
tpoint.y = tpoint.y+4;
|
2020-04-26 20:13:47 +02:00
|
|
|
//
|
2020-11-01 05:39:19 +01:00
|
|
|
|
|
|
|
drawRect = tiles_rect;
|
2020-04-26 20:13:47 +02:00
|
|
|
drawRect.x += tpoint.x;
|
|
|
|
drawRect.y += tpoint.y;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(grphx.im_tiles_white, 1166, drawRect.x, drawRect.y, 8, 8, ct);
|
2020-11-01 05:39:19 +01:00
|
|
|
}
|
|
|
|
break;
|
2023-01-02 05:16:08 +01:00
|
|
|
}
|
2020-11-01 05:39:19 +01:00
|
|
|
case 13:
|
|
|
|
{
|
|
|
|
//Special for epilogue: huge hero!
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_sprites, obj.entities[i].drawframe, xp, yp - yoff, sprites_rect.w, sprites_rect.h, obj.entities[i].realcol, 6, 6);
|
2020-11-01 05:39:19 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2020-03-31 21:26:11 +02:00
|
|
|
void Graphics::drawbackground( int t )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
switch(t)
|
|
|
|
{
|
|
|
|
case 1:
|
|
|
|
//Starfield
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(0, 0, 0);
|
2020-07-03 11:31:13 +02:00
|
|
|
for (int i = 0; i < numstars; i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
stars[i].w = 2;
|
|
|
|
stars[i].h = 2;
|
2020-04-29 04:30:37 +02:00
|
|
|
SDL_Rect star_rect = stars[i];
|
|
|
|
star_rect.x = lerp(star_rect.x + starsspeed[i], star_rect.x);
|
2020-01-01 21:29:24 +01:00
|
|
|
if (starsspeed[i] <= 6)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&star_rect, getRGB(0x22,0x22,0x22));
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&star_rect, getRGB(0x55,0x55,0x55));
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 2:
|
2020-11-02 22:02:51 +01:00
|
|
|
{
|
2023-01-02 01:36:43 +01:00
|
|
|
SDL_Color bcol;
|
|
|
|
SDL_Color bcol2;
|
|
|
|
SDL_zero(bcol);
|
|
|
|
SDL_zero(bcol2);
|
2020-11-02 22:02:51 +01:00
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
//Lab
|
|
|
|
switch(rcol)
|
|
|
|
{
|
|
|
|
//Akward ordering to match tileset
|
|
|
|
case 0:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(0, 16*backboxint[0], 16*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Cyan
|
|
|
|
case 1:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(16*backboxint[0], 0, 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Red
|
|
|
|
case 2:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(16*backboxint[0], 0, 16*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Purple
|
|
|
|
case 3:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(0, 0, 16*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Blue
|
|
|
|
case 4:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(16*backboxint[0], 16*backboxint[0], 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Yellow
|
|
|
|
case 5:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(0, 16 * backboxint[0], 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Green
|
|
|
|
case 6:
|
|
|
|
//crazy case
|
|
|
|
switch(spcol)
|
|
|
|
{
|
|
|
|
case 0:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(0, 16*backboxint[0], 16*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Cyan
|
|
|
|
case 1:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(0, (spcoldel+1)*backboxint[0], 16*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Cyan
|
|
|
|
case 2:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(0, 0, 16*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Blue
|
|
|
|
case 3:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB((16-spcoldel)*backboxint[0], 0, 16*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Blue
|
|
|
|
case 4:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(16*backboxint[0], 0, 16*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Purple
|
|
|
|
case 5:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(16*backboxint[0], 0, (spcoldel+1)*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Purple
|
|
|
|
case 6:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(16*backboxint[0], 0, 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Red
|
|
|
|
case 7:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(16*backboxint[0], (16-spcoldel)*backboxint[0], 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Red
|
|
|
|
case 8:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(16*backboxint[0], 16*backboxint[0], 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Yellow
|
|
|
|
case 9:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB((spcoldel+1)*backboxint[0], 16*backboxint[0], 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Yellow
|
|
|
|
case 10:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(0, 16 * backboxint[0], 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Green
|
|
|
|
case 11:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol2 = getRGB(0, 16 * backboxint[0], (16-spcoldel)*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Green
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(bcol2);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-07-03 11:31:13 +02:00
|
|
|
for (int i = 0; i < numbackboxes; i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
switch(rcol)
|
|
|
|
{
|
|
|
|
//Akward ordering to match tileset
|
|
|
|
case 0:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(16, 128*backboxint[0], 128*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Cyan
|
|
|
|
case 1:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(128*backboxint[0], 16, 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Red
|
|
|
|
case 2:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(128*backboxint[0], 16, 128*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Purple
|
|
|
|
case 3:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(16, 16, 128*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Blue
|
|
|
|
case 4:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(128*backboxint[0], 128*backboxint[0], 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Yellow
|
|
|
|
case 5:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(16, 128 * backboxint[0], 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Green
|
|
|
|
case 6:
|
|
|
|
//crazy case
|
|
|
|
switch(spcol)
|
|
|
|
{
|
|
|
|
case 0:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(16, 128*backboxint[0], 128*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Cyan
|
|
|
|
case 1:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(16, ((spcoldel+1)*8)*backboxint[0], 128*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Cyan
|
|
|
|
case 2:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(16, 16, 128*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Blue
|
|
|
|
case 3:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB((128-(spcoldel*8))*backboxint[0], 16, 128*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Blue
|
|
|
|
case 4:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(128*backboxint[0], 16, 128*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Purple
|
|
|
|
case 5:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(128*backboxint[0], 16, ((spcoldel+1)*8)*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Purple
|
|
|
|
case 6:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(128*backboxint[0], 16, 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Red
|
|
|
|
case 7:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(128*backboxint[0], (128-(spcoldel*8))*backboxint[0], 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Red
|
|
|
|
case 8:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(128*backboxint[0], 128*backboxint[0], 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Yellow
|
|
|
|
case 9:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(((spcoldel+1)*8)*backboxint[0], 128*backboxint[0], 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Yellow
|
|
|
|
case 10:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(16, 128 * backboxint[0], 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Green
|
|
|
|
case 11:
|
2021-09-11 11:15:20 +02:00
|
|
|
bcol = getRGB(16, 128 * backboxint[0], (128-(spcoldel*8))*backboxint[0]);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Green
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2020-04-29 04:45:18 +02:00
|
|
|
|
2020-04-29 04:54:53 +02:00
|
|
|
SDL_Rect backboxrect = backboxes[i];
|
2020-04-29 04:45:18 +02:00
|
|
|
backboxrect.x = lerp(backboxes[i].x - backboxvx[i], backboxes[i].x);
|
|
|
|
backboxrect.y = lerp(backboxes[i].y - backboxvy[i], backboxes[i].y);
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&backboxrect, bcol);
|
2020-04-29 04:45:18 +02:00
|
|
|
backboxrect.x += 1;
|
|
|
|
backboxrect.y += 1;
|
|
|
|
backboxrect.w -= 2;
|
|
|
|
backboxrect.h -= 2;
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&backboxrect, bcol2);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
break;
|
2020-11-02 22:02:51 +01:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
case 3: //Warp zone (horizontal)
|
2023-01-07 19:28:07 +01:00
|
|
|
{
|
|
|
|
clear();
|
|
|
|
|
|
|
|
const int offset = (int) lerp(0, -3);
|
|
|
|
const SDL_Rect srcRect = {8 + offset, 0, SCREEN_WIDTH_PIXELS, SCREEN_HEIGHT_PIXELS};
|
|
|
|
|
|
|
|
copy_texture(backgroundTexture, &srcRect, NULL);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
2023-01-07 19:28:07 +01:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
case 4: //Warp zone (vertical)
|
2023-01-07 19:28:07 +01:00
|
|
|
{
|
|
|
|
clear();
|
|
|
|
|
|
|
|
const int offset = (int) lerp(0, -3);
|
|
|
|
const SDL_Rect srcRect = {0, 8 + offset, SCREEN_WIDTH_PIXELS, SCREEN_HEIGHT_PIXELS};
|
|
|
|
|
|
|
|
copy_texture(backgroundTexture, &srcRect, NULL);
|
2020-01-01 21:29:24 +01:00
|
|
|
break;
|
2023-01-07 19:28:07 +01:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
case 5:
|
2023-01-02 20:15:54 +01:00
|
|
|
{
|
2020-01-01 21:29:24 +01:00
|
|
|
//Warp zone, central
|
2023-01-02 20:15:54 +01:00
|
|
|
SDL_Color warpbcol;
|
|
|
|
SDL_Color warpfcol;
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
switch(rcol)
|
|
|
|
{
|
|
|
|
//Akward ordering to match tileset
|
|
|
|
case 0:
|
2021-09-11 11:15:20 +02:00
|
|
|
warpbcol = getRGB(0x0A, 0x10, 0x0E);
|
|
|
|
warpfcol = getRGB(0x10, 0x22, 0x21);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Cyan
|
|
|
|
case 1:
|
2021-09-11 11:15:20 +02:00
|
|
|
warpbcol = getRGB(0x11, 0x09, 0x0B);
|
|
|
|
warpfcol = getRGB(0x22, 0x10, 0x11);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Red
|
|
|
|
case 2:
|
2021-09-11 11:15:20 +02:00
|
|
|
warpbcol = getRGB(0x0F, 0x0A, 0x10);
|
|
|
|
warpfcol = getRGB(0x22,0x10,0x22);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Purple
|
|
|
|
case 3:
|
2021-09-11 11:15:20 +02:00
|
|
|
warpbcol = getRGB(0x0A, 0x0B, 0x10);
|
|
|
|
warpfcol = getRGB(0x10, 0x10, 0x22);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Blue
|
|
|
|
case 4:
|
2021-09-11 11:15:20 +02:00
|
|
|
warpbcol = getRGB(0x10, 0x0D, 0x0A);
|
|
|
|
warpfcol = getRGB(0x22, 0x1E, 0x10);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Yellow
|
|
|
|
case 5:
|
2021-09-11 11:15:20 +02:00
|
|
|
warpbcol = getRGB(0x0D, 0x10, 0x0A);
|
|
|
|
warpfcol = getRGB(0x14, 0x22, 0x10);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Green
|
|
|
|
case 6:
|
2021-09-11 11:15:20 +02:00
|
|
|
warpbcol = getRGB(0x0A, 0x0A, 0x0A);
|
|
|
|
warpfcol = getRGB(0x12, 0x12, 0x12);
|
2020-01-01 21:29:24 +01:00
|
|
|
break; //Gray
|
2020-04-02 22:05:48 +02:00
|
|
|
default:
|
2021-09-11 11:15:20 +02:00
|
|
|
warpbcol = getRGB(0xFF, 0xFF, 0xFF);
|
|
|
|
warpfcol = getRGB(0xFF, 0xFF, 0xFF);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
for (int i = 10 ; i >= 0; i--)
|
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
const int temp = (i * 16) + backoffset;
|
2023-01-02 20:15:54 +01:00
|
|
|
const SDL_Rect warprect = {160 - temp, 120 - temp, temp * 2, temp * 2};
|
2020-01-01 21:29:24 +01:00
|
|
|
if (i % 2 == warpskip)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&warprect, warpbcol);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&warprect, warpfcol);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
2023-01-02 20:15:54 +01:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
case 6:
|
|
|
|
//Final Starfield
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(0, 0, 0);
|
2020-07-03 11:31:13 +02:00
|
|
|
for (int i = 0; i < numstars; i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-04-29 04:52:59 +02:00
|
|
|
stars[i].w = 2;
|
|
|
|
stars[i].h = 2;
|
|
|
|
SDL_Rect star_rect = stars[i];
|
|
|
|
star_rect.y = lerp(star_rect.y + starsspeed[i], star_rect.y);
|
2020-01-01 21:29:24 +01:00
|
|
|
if (starsspeed[i] <= 8)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&star_rect, getRGB(0x22, 0x22, 0x22));
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&star_rect, getRGB(0x55, 0x55, 0x55));
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 7:
|
|
|
|
//Static, unscrolling section of the tower
|
|
|
|
for (int j = 0; j < 30; j++)
|
|
|
|
{
|
|
|
|
for (int i = 0; i < 40; i++)
|
|
|
|
{
|
|
|
|
drawtile3(i * 8, j * 8, map.tower.backat(i, j, 200), 15);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 8:
|
|
|
|
//Static, unscrolling section of the tower
|
|
|
|
for (int j = 0; j < 30; j++)
|
|
|
|
{
|
|
|
|
for (int i = 0; i < 40; i++)
|
|
|
|
{
|
|
|
|
drawtile3(i * 8, j * 8, map.tower.backat(i, j, 200), 10);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 9:
|
|
|
|
//Static, unscrolling section of the tower
|
|
|
|
for (int j = 0; j < 30; j++)
|
|
|
|
{
|
|
|
|
for (int i = 0; i < 40; i++)
|
|
|
|
{
|
|
|
|
drawtile3(i * 8, j * 8, map.tower.backat(i, j, 600), 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(0, 0, 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-29 04:28:16 +02:00
|
|
|
void Graphics::updatebackground(int t)
|
|
|
|
{
|
|
|
|
switch (t)
|
|
|
|
{
|
|
|
|
case 1:
|
|
|
|
//Starfield
|
2020-07-03 11:31:13 +02:00
|
|
|
for (int i = 0; i < numstars; i++)
|
2020-04-29 04:28:16 +02:00
|
|
|
{
|
|
|
|
stars[i].w = 2;
|
|
|
|
stars[i].h = 2;
|
Remove unnecessary Sint16 casts
These casts are sprinkled all throughout the graphics code when creating
and initializing an SDL_Rect on the same line. Unfortunately, most of
these are unnecessary, and at worst are wasteful because they result in
narrowing a 4-byte integer into a 2-byte one when they don't need to
(SDL_Rects are made up of 4-byte integers).
Now, removing them reveals why they were placed there in the first place
- a warning is raised (-Wnarrowing) that implicit narrowing conversions
are prohibited in initializer lists in C++11. (Notably, if the
conversion wasn't narrowing, or implicit, or done in an initializer
list, it would be fine. This is a really specific prohibition that
doesn't apply if any of its sub-cases are true.)
We don't use C++11, but this warning can be easily vanquished by a
simple explicit cast to int (similar to the error of implicitly
converting void* to any other pointer in C++, which works just fine in
C), and we only need to do it when the warning is raised (not every
single time we make an SDL_Rect), so there we go.
2021-04-18 20:13:12 +02:00
|
|
|
stars[i].x -= starsspeed[i];
|
2020-04-29 04:28:16 +02:00
|
|
|
if (stars[i].x < -10)
|
|
|
|
{
|
|
|
|
stars[i].x += 340;
|
|
|
|
stars[i].y = int(fRandom() * 240);
|
|
|
|
stars[i].w = 2;
|
|
|
|
starsspeed[i] = 4+int(fRandom()*4);
|
|
|
|
}
|
|
|
|
}
|
2020-04-29 04:33:33 +02:00
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
//Lab
|
2020-04-29 04:47:37 +02:00
|
|
|
if (rcol == 6)
|
|
|
|
{
|
|
|
|
//crazy caze
|
|
|
|
spcoldel--;
|
|
|
|
if (spcoldel <= 0)
|
|
|
|
{
|
|
|
|
spcoldel = 15;
|
|
|
|
spcol++;
|
|
|
|
if (spcol >= 12) spcol = 0;
|
|
|
|
}
|
|
|
|
}
|
2020-07-03 11:31:13 +02:00
|
|
|
for (int i = 0; i < numbackboxes; i++)
|
2020-04-29 04:33:33 +02:00
|
|
|
{
|
|
|
|
backboxes[i].x += backboxvx[i];
|
|
|
|
backboxes[i].y += backboxvy[i];
|
|
|
|
if (backboxes[i].x < -40)
|
|
|
|
{
|
|
|
|
backboxes[i].x = 320;
|
|
|
|
backboxes[i].y = fRandom() * 240;
|
|
|
|
}
|
|
|
|
if (backboxes[i].x > 320)
|
|
|
|
{
|
|
|
|
backboxes[i].x = -32;
|
|
|
|
backboxes[i].y = fRandom() * 240;
|
|
|
|
}
|
|
|
|
if (backboxes[i].y < -40)
|
|
|
|
{
|
|
|
|
backboxes[i].y = 240;
|
|
|
|
backboxes[i].x = fRandom() * 320;
|
|
|
|
}
|
|
|
|
if (backboxes[i].y > 260)
|
|
|
|
{
|
|
|
|
backboxes[i].y = -32;
|
|
|
|
backboxes[i].x = fRandom() * 320;
|
|
|
|
}
|
|
|
|
}
|
2020-04-29 04:50:03 +02:00
|
|
|
break;
|
2020-04-29 19:37:56 +02:00
|
|
|
case 3: //Warp zone (horizontal)
|
2020-05-02 22:11:36 +02:00
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
const int temp = 680 + (rcol * 3);
|
2023-01-07 19:28:07 +01:00
|
|
|
backoffset += 3;
|
2020-04-29 19:37:56 +02:00
|
|
|
if (backoffset >= 16) backoffset -= 16;
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
SDL_Texture* target = SDL_GetRenderTarget(gameScreen.m_renderer);
|
|
|
|
set_render_target(backgroundTexture);
|
|
|
|
|
2020-04-29 19:37:56 +02:00
|
|
|
if (backgrounddrawn)
|
|
|
|
{
|
2023-03-04 01:02:53 +01:00
|
|
|
scroll_texture(backgroundTexture, tempScrollingTexture, -3, 0);
|
2020-04-29 19:37:56 +02:00
|
|
|
for (int j = 0; j < 15; j++)
|
|
|
|
{
|
2020-05-02 22:11:36 +02:00
|
|
|
for (int i = 0; i < 2; i++)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
drawtowertile(317 - backoffset + (i * 16), (j * 16), temp + 40); //20*16 = 320
|
2020-05-02 22:11:36 +02:00
|
|
|
drawtowertile(317 - backoffset + (i * 16) + 8, (j * 16), temp + 41);
|
|
|
|
drawtowertile(317 - backoffset + (i * 16), (j * 16) + 8, temp + 80);
|
|
|
|
drawtowertile(317 - backoffset + (i * 16) + 8, (j * 16) + 8, temp + 81);
|
|
|
|
}
|
2020-04-29 19:37:56 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
//draw the whole thing for the first time!
|
|
|
|
backoffset = 0;
|
2023-01-07 19:28:07 +01:00
|
|
|
clear();
|
2020-04-29 19:37:56 +02:00
|
|
|
for (int j = 0; j < 15; j++)
|
|
|
|
{
|
|
|
|
for (int i = 0; i < 21; i++)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
drawtowertile((i * 16) - backoffset - 3, (j * 16), temp + 40);
|
2020-04-29 19:37:56 +02:00
|
|
|
drawtowertile((i * 16) - backoffset + 8 - 3, (j * 16), temp + 41);
|
|
|
|
drawtowertile((i * 16) - backoffset - 3, (j * 16) + 8, temp + 80);
|
|
|
|
drawtowertile((i * 16) - backoffset + 8 - 3, (j * 16) + 8, temp + 81);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
backgrounddrawn = true;
|
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
set_render_target(target);
|
2020-04-29 19:37:56 +02:00
|
|
|
break;
|
2020-05-02 22:11:36 +02:00
|
|
|
}
|
2020-04-29 20:06:03 +02:00
|
|
|
case 4: //Warp zone (vertical)
|
2020-05-02 22:11:36 +02:00
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
const int temp = 760 + (rcol * 3);
|
2023-01-07 19:28:07 +01:00
|
|
|
backoffset += 3;
|
2020-04-29 20:06:03 +02:00
|
|
|
if (backoffset >= 16) backoffset -= 16;
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
SDL_Texture* target = SDL_GetRenderTarget(gameScreen.m_renderer);
|
|
|
|
set_render_target(backgroundTexture);
|
|
|
|
|
2020-04-29 20:06:03 +02:00
|
|
|
if (backgrounddrawn)
|
|
|
|
{
|
2023-03-04 01:02:53 +01:00
|
|
|
scroll_texture(backgroundTexture, tempScrollingTexture, 0, -3);
|
2020-05-02 22:11:36 +02:00
|
|
|
for (int j = 0; j < 2; j++)
|
2020-04-29 20:06:03 +02:00
|
|
|
{
|
2020-05-02 22:11:36 +02:00
|
|
|
for (int i = 0; i < 21; i++)
|
|
|
|
{
|
|
|
|
drawtowertile((i * 16), 237 - backoffset + (j * 16), temp + 40); //14*17=240 - 3
|
|
|
|
drawtowertile((i * 16) + 8, 237 - backoffset + (j * 16), temp + 41);
|
|
|
|
drawtowertile((i * 16), 237 - backoffset + (j * 16) + 8, temp + 80);
|
|
|
|
drawtowertile((i * 16) + 8, 237 - backoffset + (j * 16) + 8, temp + 81);
|
|
|
|
}
|
2020-04-29 20:06:03 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
//draw the whole thing for the first time!
|
|
|
|
backoffset = 0;
|
2023-01-07 19:28:07 +01:00
|
|
|
clear();
|
2020-05-02 22:11:36 +02:00
|
|
|
for (int j = 0; j < 16; j++)
|
2020-04-29 20:06:03 +02:00
|
|
|
{
|
|
|
|
for (int i = 0; i < 21; i++)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
drawtowertile((i * 16), (j * 16) - backoffset - 3, temp + 40);
|
|
|
|
drawtowertile((i * 16) + 8, (j * 16) - backoffset - 3, temp + 41);
|
|
|
|
drawtowertile((i * 16), (j * 16) - backoffset + 8 - 3, temp + 80);
|
|
|
|
drawtowertile((i * 16) + 8, (j * 16) - backoffset + 8 - 3, temp + 81);
|
2020-04-29 20:06:03 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
backgrounddrawn = true;
|
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
set_render_target(target);
|
2020-04-29 20:06:03 +02:00
|
|
|
break;
|
2020-05-02 22:11:36 +02:00
|
|
|
}
|
2020-04-30 00:37:39 +02:00
|
|
|
case 5:
|
|
|
|
//Warp zone, central
|
|
|
|
|
|
|
|
backoffset += 1;
|
|
|
|
if (backoffset >= 16)
|
|
|
|
{
|
|
|
|
backoffset -= 16;
|
|
|
|
warpskip = (warpskip + 1) % 2;
|
|
|
|
}
|
|
|
|
break;
|
2020-04-29 04:50:03 +02:00
|
|
|
case 6:
|
|
|
|
//Final Starfield
|
2020-07-03 11:31:13 +02:00
|
|
|
for (int i = 0; i < numstars; i++)
|
2020-04-29 04:50:03 +02:00
|
|
|
{
|
|
|
|
stars[i].w = 2;
|
|
|
|
stars[i].h = 2;
|
|
|
|
stars[i].y -= starsspeed[i];
|
|
|
|
if (stars[i].y < -10)
|
|
|
|
{
|
|
|
|
stars[i].y += 260;
|
|
|
|
stars[i].x = fRandom() * 320;
|
|
|
|
starsspeed[i] = 5+(fRandom()*5);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
2020-04-29 04:28:16 +02: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 Graphics::drawmap(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
if (!foregrounddrawn)
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
SDL_Texture* target = SDL_GetRenderTarget(gameScreen.m_renderer);
|
|
|
|
|
|
|
|
set_render_target(foregroundTexture);
|
|
|
|
set_blendmode(foregroundTexture, SDL_BLENDMODE_BLEND);
|
|
|
|
clear(0, 0, 0, 0);
|
|
|
|
|
|
|
|
if (map.tileset == 0)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-06-14 20:21:32 +02:00
|
|
|
for (int j = 0; j < 30; j++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
for (int i = 0; i < 40; i++)
|
|
|
|
{
|
2021-09-25 01:37:27 +02:00
|
|
|
const int tile = map.contents[TILE_IDX(i, j)];
|
2023-01-07 19:28:07 +01:00
|
|
|
if (tile > 0) drawforetile(i * 8, j * 8, tile);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (map.tileset == 1)
|
|
|
|
{
|
Add and draw one more row to all rooms with roomnames
Since translucent roomname backgrounds were introduced in
TerryCavanagh/VVVVVV#122, it exposes one glaring flaw with the game that
until now has been kept hidden: in rooms with room names, the game
cheapens out with the tile data and doesn't have a 30th row, because the
room name would hide the missing row. As a result, rooms with room names
have 29 rows instead of 30 to fill up the entire screen. And it looks
really weird when there's nothing but empty space behind the translucent
room name background.
To remedy this, I added one row to each room with a room name in the level.
First, I had to filter out all the rooms with no room names. However, that's
actually all contained in Otherlevel.cpp, the Overworld, which contains 221
rooms (8 of which are the Secret Lab, 6 more of which are the Ship, so 207 are
the actual Overworld, right? Wrong, 2 of those Overworld no-roomname rooms are
in the Lab, so there are actually 205 Overworld rooms). The remaining level
data files all contain rooms with room names.
But the process wasn't that easy. I noticed a while ago that each room
contains 29 `tmap.push_back()`s, one for each row of the room, and each row is
simply a string containing the 40 tiles for that row, concatenated with
commas.
However, I decided to actually check my intuition by doing a grep on each
level file and counting the number of results, for example `grep 'push_back'
Labclass.cpp | wc -l`. Whatever number comes out should be divisible by 29.
That particular grep on Labclass.cpp returns 1306, which divided by 29 is 45
with a remainder of 1.
So what does that mean? Does that mean there's 45 rooms each, and 1 leftover
row? Well, not exactly. The extra row comes from the fact that Outer Space has
30 rows instead of 29. Outer Space is the room that comes up when the game
finds a room is non-existent, which shouldn't happen with a properly-working
game, except in Outside Dimension VVVVVV. In fact, each level file has their
own Outer Space, and every single Outer Space also has 30 rooms. So really,
this means there are 44 rooms in the Lab and one Outer Space room. (Well, in
reality, there are 46 rooms in the Lab, because 2 of them use the Outside
tileset but have no room names, so they're stored in Otherlevel.cpp instead.)
We find the same result for the Warp Zone. `grep 'push_back' WarpClass.cpp |
wc -l` returns 697, which is 24 remainder 1, meaning 23 rooms of 29 rows and 1
room of 30 rows, which corresponds with 23 rooms in the Warp Zone and one
Outer Space room.
However, Outside Dimension VVVVVV + Tower Hallways and Space Station 1 and 2
are both odd curiosities. Finalclass.cpp contains Outside Dimension VVVVVV,
(which is Intermission 1 and 2 and the Final Level), but also the Tower
Hallway rooms, i.e. the auxiliary Tower rooms that are not a part of the main
tower. Spacestation2.cpp contains both Space Station 1 and 2, so don't be
deceived by the name.
`grep 'push_back' Finalclass.cpp | wc -l` returns 1597, which is actually 55
remainder 2. So... are there two rooms with 30 rows? Yes, in fact, The
Gravitron and Outer Space both contain 30 rows. So there are actually 55 rooms
stored in Finalclass.cpp (not including the minitowers Panic Room and The
Final Challenge), 54 rooms of actual level data and one Outer Space room, and
breaking down the 54 rooms even further, 51 of them are actually in Outside
Dimension VVVVVV and 3 of them are Tower Hallways. Of the 51 Outside Dimension
VVVVVV rooms, 14 of those are Intermission 1, 4 of them are Intermission 2,
and the rest of the 33 rooms are the Final Level (again, not including the
minitowers).
`grep 'push_back' Spacestation2.cpp | wc -l` returns 2148, which is 74
remainder 2. Are there two rooms with 30 rows again? No; one of those counted
2148 rows is a false-positive, because there's an if-else in Prize for the
Reckless that replaces the row with spikes with a row without spikes if you
are in a time trial or in No Death Mode. So there's 73 rooms in Space Station
1 and 2, and one Outer Space room.
With all this in mind, I decided to duplicate the current last row of each
room, the 29th row, to add a 30th row. However, I wasn't going to do this
automatically! But neither was I going to write some kludge-y code to parse
each nightmare of a level file and duplicate the rows that way.
Enter: Vim macros! (Er, well, actually, I use Neovim.) I first did
`/push_back`, so that pressing `n` would keep going to the next `push_back` in
the file. Then I went to the 29th row of the first room in the file, did a
`Yp`, and then started my macro with `qq`. The macro went like this: `30nYp`,
which is simply going to the 29th row of the next room over and duplicating
it. And that's all there was to it. However, I had to make sure that (1) my
cursor was before the `push_back` on the line of the 29th row of the room, and
(2) that I didn't skip rooms, both of which were problems I encountered when
pressing Ctrl+Z a given invocation of the macro (the Ctrl+Z is just a
metaphor, you actually undo by typing `u` in Vim). And also I had to make sure
to be careful around the extra lines of `push_back`s in Prize for the Reckless
and The Gravitron, and make sure I didn't run past the end of the file and
loop back around. Thankfully, all Outer Space rooms are at the end of each
file.
But first, I had to increase the number of rows drawn in Graphics.cpp by 1 in
order to compensate for this, and do the same when reading the tile data in
Map.cpp. I had to change fillcontent(), drawmap(), drawfinalmap(),
drawtowermap(), and drawtowermap_nobackground(). Funnily enough, the tower
functions already used 30 rows, but I guess it's an off-by-one due to the
camera scrolling, so they now draw 31 rows each.
Then, I went in-game to make sure that the row behind each room name looked
fine. I checked EVERY single room with a room name. I turned on invincibility
mode and added a temporary line to hardreset() that always turned on
game.nocutscenes for a smoother playtesting experience. And to make sure that
rooms which have entirely empty bottom rows actually still have 30 rows,
instead of having 29 and the game assuming that the 30th row was empty
(because that sounds like it could lead to Undefined Behavior), I added this
temporary debugging line to the start of mapclass::fillcontent():
printf("(%i,%i) has %i rows\n", game.roomx, game.roomy, (int) tmap.size());
Everywhere I checked - and I made sure to check all rooms - every room had 30
rows and not 29 rows.
Unfortunately, some rooms simply couldn't be left alone with their 29th row
duplicated and had to be manually edited. This was because the 29th row would
contain some edge tiles because the player would be able to walk somewhere on
the 28th, 27th, and 26th rows, and if you duplicated said edge tiles behind
the room name, it would look bad.
Here's a list of rooms whose 30th rows I had to manually edit:
- Comms Relay
- The Yes Men
- Stop and Reflect
- They Call Him Flipper
- Double-slit Experiment
- Square Root
- Brought to you by the letter G
- The Bernoulli Principle
- Purest Unobtainium
- I Smell Ozone
- Conveying a New Idea
- Upstream Downstream
- Give Me A V
- $eeing Dollar $ign$
- Doing Things The Hard Way
- Very Good
- Must I Do Everything For You?
- Now Stay Close To Me...
- ...But Not Too Close
- ...Not as I Do
- Do Try To Keep Up
- Whee Sports
- As you like it
This is actually a strange case where it looked bad because of the 29th
row, instead of the 30th row, and I had to change the 29th row instead of
the 30th row to fix it.
- Maze With No Entrance
- Ascending and Descending
- Mind The Gap
Same strange case as "As you like it" (it's the 29th row I had to change
that was the problem, not the 30th).
- 1950 Silverstone Grand V
- The Villi People
I found that Panic Room and The Final Challenge also looked strange behind the
roomname background, but I can't do much about either because towers' tile
data wrap around at the top and bottom, and if I added another row to either
it would be visible above the room name.
I've considered updating the development editors with these new level tiles,
but I decided against it as the development editors are already pretty
outdated anyway.
2020-02-03 22:24:30 +01:00
|
|
|
for (int jt = 0; jt < 30; jt++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
for (int it = 0; it < 40; it++)
|
|
|
|
{
|
2021-09-25 01:37:27 +02:00
|
|
|
const int tile = map.contents[TILE_IDX(it, jt)];
|
2023-01-07 19:28:07 +01:00
|
|
|
if (tile > 0) drawforetile2(it * 8, jt * 8, tile);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (map.tileset == 2)
|
|
|
|
{
|
2020-06-14 20:21:32 +02:00
|
|
|
for (int j = 0; j < 30; j++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
for (int i = 0; i < 40; i++)
|
|
|
|
{
|
2021-09-25 01:37:27 +02:00
|
|
|
const int tile = map.contents[TILE_IDX(i, j)];
|
2023-01-07 19:28:07 +01:00
|
|
|
if (tile > 0) drawforetile3(i * 8, j * 8, tile, map.rcol);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
set_render_target(target);
|
2020-01-01 21:29:24 +01:00
|
|
|
foregrounddrawn = true;
|
|
|
|
}
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
copy_texture(foregroundTexture, NULL, NULL);
|
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 Graphics::drawfinalmap(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
if (!foregrounddrawn)
|
|
|
|
{
|
|
|
|
SDL_Texture* target = SDL_GetRenderTarget(gameScreen.m_renderer);
|
|
|
|
|
|
|
|
set_render_target(foregroundTexture);
|
|
|
|
set_blendmode(foregroundTexture, SDL_BLENDMODE_BLEND);
|
|
|
|
clear(0, 0, 0, 0);
|
|
|
|
if (map.tileset == 0) {
|
Add and draw one more row to all rooms with roomnames
Since translucent roomname backgrounds were introduced in
TerryCavanagh/VVVVVV#122, it exposes one glaring flaw with the game that
until now has been kept hidden: in rooms with room names, the game
cheapens out with the tile data and doesn't have a 30th row, because the
room name would hide the missing row. As a result, rooms with room names
have 29 rows instead of 30 to fill up the entire screen. And it looks
really weird when there's nothing but empty space behind the translucent
room name background.
To remedy this, I added one row to each room with a room name in the level.
First, I had to filter out all the rooms with no room names. However, that's
actually all contained in Otherlevel.cpp, the Overworld, which contains 221
rooms (8 of which are the Secret Lab, 6 more of which are the Ship, so 207 are
the actual Overworld, right? Wrong, 2 of those Overworld no-roomname rooms are
in the Lab, so there are actually 205 Overworld rooms). The remaining level
data files all contain rooms with room names.
But the process wasn't that easy. I noticed a while ago that each room
contains 29 `tmap.push_back()`s, one for each row of the room, and each row is
simply a string containing the 40 tiles for that row, concatenated with
commas.
However, I decided to actually check my intuition by doing a grep on each
level file and counting the number of results, for example `grep 'push_back'
Labclass.cpp | wc -l`. Whatever number comes out should be divisible by 29.
That particular grep on Labclass.cpp returns 1306, which divided by 29 is 45
with a remainder of 1.
So what does that mean? Does that mean there's 45 rooms each, and 1 leftover
row? Well, not exactly. The extra row comes from the fact that Outer Space has
30 rows instead of 29. Outer Space is the room that comes up when the game
finds a room is non-existent, which shouldn't happen with a properly-working
game, except in Outside Dimension VVVVVV. In fact, each level file has their
own Outer Space, and every single Outer Space also has 30 rooms. So really,
this means there are 44 rooms in the Lab and one Outer Space room. (Well, in
reality, there are 46 rooms in the Lab, because 2 of them use the Outside
tileset but have no room names, so they're stored in Otherlevel.cpp instead.)
We find the same result for the Warp Zone. `grep 'push_back' WarpClass.cpp |
wc -l` returns 697, which is 24 remainder 1, meaning 23 rooms of 29 rows and 1
room of 30 rows, which corresponds with 23 rooms in the Warp Zone and one
Outer Space room.
However, Outside Dimension VVVVVV + Tower Hallways and Space Station 1 and 2
are both odd curiosities. Finalclass.cpp contains Outside Dimension VVVVVV,
(which is Intermission 1 and 2 and the Final Level), but also the Tower
Hallway rooms, i.e. the auxiliary Tower rooms that are not a part of the main
tower. Spacestation2.cpp contains both Space Station 1 and 2, so don't be
deceived by the name.
`grep 'push_back' Finalclass.cpp | wc -l` returns 1597, which is actually 55
remainder 2. So... are there two rooms with 30 rows? Yes, in fact, The
Gravitron and Outer Space both contain 30 rows. So there are actually 55 rooms
stored in Finalclass.cpp (not including the minitowers Panic Room and The
Final Challenge), 54 rooms of actual level data and one Outer Space room, and
breaking down the 54 rooms even further, 51 of them are actually in Outside
Dimension VVVVVV and 3 of them are Tower Hallways. Of the 51 Outside Dimension
VVVVVV rooms, 14 of those are Intermission 1, 4 of them are Intermission 2,
and the rest of the 33 rooms are the Final Level (again, not including the
minitowers).
`grep 'push_back' Spacestation2.cpp | wc -l` returns 2148, which is 74
remainder 2. Are there two rooms with 30 rows again? No; one of those counted
2148 rows is a false-positive, because there's an if-else in Prize for the
Reckless that replaces the row with spikes with a row without spikes if you
are in a time trial or in No Death Mode. So there's 73 rooms in Space Station
1 and 2, and one Outer Space room.
With all this in mind, I decided to duplicate the current last row of each
room, the 29th row, to add a 30th row. However, I wasn't going to do this
automatically! But neither was I going to write some kludge-y code to parse
each nightmare of a level file and duplicate the rows that way.
Enter: Vim macros! (Er, well, actually, I use Neovim.) I first did
`/push_back`, so that pressing `n` would keep going to the next `push_back` in
the file. Then I went to the 29th row of the first room in the file, did a
`Yp`, and then started my macro with `qq`. The macro went like this: `30nYp`,
which is simply going to the 29th row of the next room over and duplicating
it. And that's all there was to it. However, I had to make sure that (1) my
cursor was before the `push_back` on the line of the 29th row of the room, and
(2) that I didn't skip rooms, both of which were problems I encountered when
pressing Ctrl+Z a given invocation of the macro (the Ctrl+Z is just a
metaphor, you actually undo by typing `u` in Vim). And also I had to make sure
to be careful around the extra lines of `push_back`s in Prize for the Reckless
and The Gravitron, and make sure I didn't run past the end of the file and
loop back around. Thankfully, all Outer Space rooms are at the end of each
file.
But first, I had to increase the number of rows drawn in Graphics.cpp by 1 in
order to compensate for this, and do the same when reading the tile data in
Map.cpp. I had to change fillcontent(), drawmap(), drawfinalmap(),
drawtowermap(), and drawtowermap_nobackground(). Funnily enough, the tower
functions already used 30 rows, but I guess it's an off-by-one due to the
camera scrolling, so they now draw 31 rows each.
Then, I went in-game to make sure that the row behind each room name looked
fine. I checked EVERY single room with a room name. I turned on invincibility
mode and added a temporary line to hardreset() that always turned on
game.nocutscenes for a smoother playtesting experience. And to make sure that
rooms which have entirely empty bottom rows actually still have 30 rows,
instead of having 29 and the game assuming that the 30th row was empty
(because that sounds like it could lead to Undefined Behavior), I added this
temporary debugging line to the start of mapclass::fillcontent():
printf("(%i,%i) has %i rows\n", game.roomx, game.roomy, (int) tmap.size());
Everywhere I checked - and I made sure to check all rooms - every room had 30
rows and not 29 rows.
Unfortunately, some rooms simply couldn't be left alone with their 29th row
duplicated and had to be manually edited. This was because the 29th row would
contain some edge tiles because the player would be able to walk somewhere on
the 28th, 27th, and 26th rows, and if you duplicated said edge tiles behind
the room name, it would look bad.
Here's a list of rooms whose 30th rows I had to manually edit:
- Comms Relay
- The Yes Men
- Stop and Reflect
- They Call Him Flipper
- Double-slit Experiment
- Square Root
- Brought to you by the letter G
- The Bernoulli Principle
- Purest Unobtainium
- I Smell Ozone
- Conveying a New Idea
- Upstream Downstream
- Give Me A V
- $eeing Dollar $ign$
- Doing Things The Hard Way
- Very Good
- Must I Do Everything For You?
- Now Stay Close To Me...
- ...But Not Too Close
- ...Not as I Do
- Do Try To Keep Up
- Whee Sports
- As you like it
This is actually a strange case where it looked bad because of the 29th
row, instead of the 30th row, and I had to change the 29th row instead of
the 30th row to fix it.
- Maze With No Entrance
- Ascending and Descending
- Mind The Gap
Same strange case as "As you like it" (it's the 29th row I had to change
that was the problem, not the 30th).
- 1950 Silverstone Grand V
- The Villi People
I found that Panic Room and The Final Challenge also looked strange behind the
roomname background, but I can't do much about either because towers' tile
data wrap around at the top and bottom, and if I added another row to either
it would be visible above the room name.
I've considered updating the development editors with these new level tiles,
but I decided against it as the development editors are already pretty
outdated anyway.
2020-02-03 22:24:30 +01:00
|
|
|
for (int j = 0; j < 30; j++) {
|
2020-04-02 22:05:48 +02:00
|
|
|
for (int i = 0; i < 40; i++) {
|
2023-01-07 19:28:07 +01:00
|
|
|
if ((map.contents[TILE_IDX(i, j)]) > 0)
|
|
|
|
drawforetile(i * 8, j * 8, map.finalat(i, j));
|
2020-04-02 22:05:48 +02:00
|
|
|
}
|
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
}
|
|
|
|
else if (map.tileset == 1) {
|
Add and draw one more row to all rooms with roomnames
Since translucent roomname backgrounds were introduced in
TerryCavanagh/VVVVVV#122, it exposes one glaring flaw with the game that
until now has been kept hidden: in rooms with room names, the game
cheapens out with the tile data and doesn't have a 30th row, because the
room name would hide the missing row. As a result, rooms with room names
have 29 rows instead of 30 to fill up the entire screen. And it looks
really weird when there's nothing but empty space behind the translucent
room name background.
To remedy this, I added one row to each room with a room name in the level.
First, I had to filter out all the rooms with no room names. However, that's
actually all contained in Otherlevel.cpp, the Overworld, which contains 221
rooms (8 of which are the Secret Lab, 6 more of which are the Ship, so 207 are
the actual Overworld, right? Wrong, 2 of those Overworld no-roomname rooms are
in the Lab, so there are actually 205 Overworld rooms). The remaining level
data files all contain rooms with room names.
But the process wasn't that easy. I noticed a while ago that each room
contains 29 `tmap.push_back()`s, one for each row of the room, and each row is
simply a string containing the 40 tiles for that row, concatenated with
commas.
However, I decided to actually check my intuition by doing a grep on each
level file and counting the number of results, for example `grep 'push_back'
Labclass.cpp | wc -l`. Whatever number comes out should be divisible by 29.
That particular grep on Labclass.cpp returns 1306, which divided by 29 is 45
with a remainder of 1.
So what does that mean? Does that mean there's 45 rooms each, and 1 leftover
row? Well, not exactly. The extra row comes from the fact that Outer Space has
30 rows instead of 29. Outer Space is the room that comes up when the game
finds a room is non-existent, which shouldn't happen with a properly-working
game, except in Outside Dimension VVVVVV. In fact, each level file has their
own Outer Space, and every single Outer Space also has 30 rooms. So really,
this means there are 44 rooms in the Lab and one Outer Space room. (Well, in
reality, there are 46 rooms in the Lab, because 2 of them use the Outside
tileset but have no room names, so they're stored in Otherlevel.cpp instead.)
We find the same result for the Warp Zone. `grep 'push_back' WarpClass.cpp |
wc -l` returns 697, which is 24 remainder 1, meaning 23 rooms of 29 rows and 1
room of 30 rows, which corresponds with 23 rooms in the Warp Zone and one
Outer Space room.
However, Outside Dimension VVVVVV + Tower Hallways and Space Station 1 and 2
are both odd curiosities. Finalclass.cpp contains Outside Dimension VVVVVV,
(which is Intermission 1 and 2 and the Final Level), but also the Tower
Hallway rooms, i.e. the auxiliary Tower rooms that are not a part of the main
tower. Spacestation2.cpp contains both Space Station 1 and 2, so don't be
deceived by the name.
`grep 'push_back' Finalclass.cpp | wc -l` returns 1597, which is actually 55
remainder 2. So... are there two rooms with 30 rows? Yes, in fact, The
Gravitron and Outer Space both contain 30 rows. So there are actually 55 rooms
stored in Finalclass.cpp (not including the minitowers Panic Room and The
Final Challenge), 54 rooms of actual level data and one Outer Space room, and
breaking down the 54 rooms even further, 51 of them are actually in Outside
Dimension VVVVVV and 3 of them are Tower Hallways. Of the 51 Outside Dimension
VVVVVV rooms, 14 of those are Intermission 1, 4 of them are Intermission 2,
and the rest of the 33 rooms are the Final Level (again, not including the
minitowers).
`grep 'push_back' Spacestation2.cpp | wc -l` returns 2148, which is 74
remainder 2. Are there two rooms with 30 rows again? No; one of those counted
2148 rows is a false-positive, because there's an if-else in Prize for the
Reckless that replaces the row with spikes with a row without spikes if you
are in a time trial or in No Death Mode. So there's 73 rooms in Space Station
1 and 2, and one Outer Space room.
With all this in mind, I decided to duplicate the current last row of each
room, the 29th row, to add a 30th row. However, I wasn't going to do this
automatically! But neither was I going to write some kludge-y code to parse
each nightmare of a level file and duplicate the rows that way.
Enter: Vim macros! (Er, well, actually, I use Neovim.) I first did
`/push_back`, so that pressing `n` would keep going to the next `push_back` in
the file. Then I went to the 29th row of the first room in the file, did a
`Yp`, and then started my macro with `qq`. The macro went like this: `30nYp`,
which is simply going to the 29th row of the next room over and duplicating
it. And that's all there was to it. However, I had to make sure that (1) my
cursor was before the `push_back` on the line of the 29th row of the room, and
(2) that I didn't skip rooms, both of which were problems I encountered when
pressing Ctrl+Z a given invocation of the macro (the Ctrl+Z is just a
metaphor, you actually undo by typing `u` in Vim). And also I had to make sure
to be careful around the extra lines of `push_back`s in Prize for the Reckless
and The Gravitron, and make sure I didn't run past the end of the file and
loop back around. Thankfully, all Outer Space rooms are at the end of each
file.
But first, I had to increase the number of rows drawn in Graphics.cpp by 1 in
order to compensate for this, and do the same when reading the tile data in
Map.cpp. I had to change fillcontent(), drawmap(), drawfinalmap(),
drawtowermap(), and drawtowermap_nobackground(). Funnily enough, the tower
functions already used 30 rows, but I guess it's an off-by-one due to the
camera scrolling, so they now draw 31 rows each.
Then, I went in-game to make sure that the row behind each room name looked
fine. I checked EVERY single room with a room name. I turned on invincibility
mode and added a temporary line to hardreset() that always turned on
game.nocutscenes for a smoother playtesting experience. And to make sure that
rooms which have entirely empty bottom rows actually still have 30 rows,
instead of having 29 and the game assuming that the 30th row was empty
(because that sounds like it could lead to Undefined Behavior), I added this
temporary debugging line to the start of mapclass::fillcontent():
printf("(%i,%i) has %i rows\n", game.roomx, game.roomy, (int) tmap.size());
Everywhere I checked - and I made sure to check all rooms - every room had 30
rows and not 29 rows.
Unfortunately, some rooms simply couldn't be left alone with their 29th row
duplicated and had to be manually edited. This was because the 29th row would
contain some edge tiles because the player would be able to walk somewhere on
the 28th, 27th, and 26th rows, and if you duplicated said edge tiles behind
the room name, it would look bad.
Here's a list of rooms whose 30th rows I had to manually edit:
- Comms Relay
- The Yes Men
- Stop and Reflect
- They Call Him Flipper
- Double-slit Experiment
- Square Root
- Brought to you by the letter G
- The Bernoulli Principle
- Purest Unobtainium
- I Smell Ozone
- Conveying a New Idea
- Upstream Downstream
- Give Me A V
- $eeing Dollar $ign$
- Doing Things The Hard Way
- Very Good
- Must I Do Everything For You?
- Now Stay Close To Me...
- ...But Not Too Close
- ...Not as I Do
- Do Try To Keep Up
- Whee Sports
- As you like it
This is actually a strange case where it looked bad because of the 29th
row, instead of the 30th row, and I had to change the 29th row instead of
the 30th row to fix it.
- Maze With No Entrance
- Ascending and Descending
- Mind The Gap
Same strange case as "As you like it" (it's the 29th row I had to change
that was the problem, not the 30th).
- 1950 Silverstone Grand V
- The Villi People
I found that Panic Room and The Final Challenge also looked strange behind the
roomname background, but I can't do much about either because towers' tile
data wrap around at the top and bottom, and if I added another row to either
it would be visible above the room name.
I've considered updating the development editors with these new level tiles,
but I decided against it as the development editors are already pretty
outdated anyway.
2020-02-03 22:24:30 +01:00
|
|
|
for (int j = 0; j < 30; j++) {
|
2020-04-02 22:05:48 +02:00
|
|
|
for (int i = 0; i < 40; i++) {
|
2023-01-07 19:28:07 +01:00
|
|
|
if ((map.contents[TILE_IDX(i, j)]) > 0)
|
|
|
|
drawforetile2(i * 8, j * 8, map.finalat(i, j));
|
2020-04-02 22:05:48 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
set_render_target(target);
|
|
|
|
foregrounddrawn = true;
|
2020-04-02 22:05:48 +02:00
|
|
|
}
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
copy_texture(foregroundTexture, NULL, NULL);
|
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 Graphics::drawtowermap(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
const int yoff = lerp(map.oldypos, map.ypos);
|
Add and draw one more row to all rooms with roomnames
Since translucent roomname backgrounds were introduced in
TerryCavanagh/VVVVVV#122, it exposes one glaring flaw with the game that
until now has been kept hidden: in rooms with room names, the game
cheapens out with the tile data and doesn't have a 30th row, because the
room name would hide the missing row. As a result, rooms with room names
have 29 rows instead of 30 to fill up the entire screen. And it looks
really weird when there's nothing but empty space behind the translucent
room name background.
To remedy this, I added one row to each room with a room name in the level.
First, I had to filter out all the rooms with no room names. However, that's
actually all contained in Otherlevel.cpp, the Overworld, which contains 221
rooms (8 of which are the Secret Lab, 6 more of which are the Ship, so 207 are
the actual Overworld, right? Wrong, 2 of those Overworld no-roomname rooms are
in the Lab, so there are actually 205 Overworld rooms). The remaining level
data files all contain rooms with room names.
But the process wasn't that easy. I noticed a while ago that each room
contains 29 `tmap.push_back()`s, one for each row of the room, and each row is
simply a string containing the 40 tiles for that row, concatenated with
commas.
However, I decided to actually check my intuition by doing a grep on each
level file and counting the number of results, for example `grep 'push_back'
Labclass.cpp | wc -l`. Whatever number comes out should be divisible by 29.
That particular grep on Labclass.cpp returns 1306, which divided by 29 is 45
with a remainder of 1.
So what does that mean? Does that mean there's 45 rooms each, and 1 leftover
row? Well, not exactly. The extra row comes from the fact that Outer Space has
30 rows instead of 29. Outer Space is the room that comes up when the game
finds a room is non-existent, which shouldn't happen with a properly-working
game, except in Outside Dimension VVVVVV. In fact, each level file has their
own Outer Space, and every single Outer Space also has 30 rooms. So really,
this means there are 44 rooms in the Lab and one Outer Space room. (Well, in
reality, there are 46 rooms in the Lab, because 2 of them use the Outside
tileset but have no room names, so they're stored in Otherlevel.cpp instead.)
We find the same result for the Warp Zone. `grep 'push_back' WarpClass.cpp |
wc -l` returns 697, which is 24 remainder 1, meaning 23 rooms of 29 rows and 1
room of 30 rows, which corresponds with 23 rooms in the Warp Zone and one
Outer Space room.
However, Outside Dimension VVVVVV + Tower Hallways and Space Station 1 and 2
are both odd curiosities. Finalclass.cpp contains Outside Dimension VVVVVV,
(which is Intermission 1 and 2 and the Final Level), but also the Tower
Hallway rooms, i.e. the auxiliary Tower rooms that are not a part of the main
tower. Spacestation2.cpp contains both Space Station 1 and 2, so don't be
deceived by the name.
`grep 'push_back' Finalclass.cpp | wc -l` returns 1597, which is actually 55
remainder 2. So... are there two rooms with 30 rows? Yes, in fact, The
Gravitron and Outer Space both contain 30 rows. So there are actually 55 rooms
stored in Finalclass.cpp (not including the minitowers Panic Room and The
Final Challenge), 54 rooms of actual level data and one Outer Space room, and
breaking down the 54 rooms even further, 51 of them are actually in Outside
Dimension VVVVVV and 3 of them are Tower Hallways. Of the 51 Outside Dimension
VVVVVV rooms, 14 of those are Intermission 1, 4 of them are Intermission 2,
and the rest of the 33 rooms are the Final Level (again, not including the
minitowers).
`grep 'push_back' Spacestation2.cpp | wc -l` returns 2148, which is 74
remainder 2. Are there two rooms with 30 rows again? No; one of those counted
2148 rows is a false-positive, because there's an if-else in Prize for the
Reckless that replaces the row with spikes with a row without spikes if you
are in a time trial or in No Death Mode. So there's 73 rooms in Space Station
1 and 2, and one Outer Space room.
With all this in mind, I decided to duplicate the current last row of each
room, the 29th row, to add a 30th row. However, I wasn't going to do this
automatically! But neither was I going to write some kludge-y code to parse
each nightmare of a level file and duplicate the rows that way.
Enter: Vim macros! (Er, well, actually, I use Neovim.) I first did
`/push_back`, so that pressing `n` would keep going to the next `push_back` in
the file. Then I went to the 29th row of the first room in the file, did a
`Yp`, and then started my macro with `qq`. The macro went like this: `30nYp`,
which is simply going to the 29th row of the next room over and duplicating
it. And that's all there was to it. However, I had to make sure that (1) my
cursor was before the `push_back` on the line of the 29th row of the room, and
(2) that I didn't skip rooms, both of which were problems I encountered when
pressing Ctrl+Z a given invocation of the macro (the Ctrl+Z is just a
metaphor, you actually undo by typing `u` in Vim). And also I had to make sure
to be careful around the extra lines of `push_back`s in Prize for the Reckless
and The Gravitron, and make sure I didn't run past the end of the file and
loop back around. Thankfully, all Outer Space rooms are at the end of each
file.
But first, I had to increase the number of rows drawn in Graphics.cpp by 1 in
order to compensate for this, and do the same when reading the tile data in
Map.cpp. I had to change fillcontent(), drawmap(), drawfinalmap(),
drawtowermap(), and drawtowermap_nobackground(). Funnily enough, the tower
functions already used 30 rows, but I guess it's an off-by-one due to the
camera scrolling, so they now draw 31 rows each.
Then, I went in-game to make sure that the row behind each room name looked
fine. I checked EVERY single room with a room name. I turned on invincibility
mode and added a temporary line to hardreset() that always turned on
game.nocutscenes for a smoother playtesting experience. And to make sure that
rooms which have entirely empty bottom rows actually still have 30 rows,
instead of having 29 and the game assuming that the 30th row was empty
(because that sounds like it could lead to Undefined Behavior), I added this
temporary debugging line to the start of mapclass::fillcontent():
printf("(%i,%i) has %i rows\n", game.roomx, game.roomy, (int) tmap.size());
Everywhere I checked - and I made sure to check all rooms - every room had 30
rows and not 29 rows.
Unfortunately, some rooms simply couldn't be left alone with their 29th row
duplicated and had to be manually edited. This was because the 29th row would
contain some edge tiles because the player would be able to walk somewhere on
the 28th, 27th, and 26th rows, and if you duplicated said edge tiles behind
the room name, it would look bad.
Here's a list of rooms whose 30th rows I had to manually edit:
- Comms Relay
- The Yes Men
- Stop and Reflect
- They Call Him Flipper
- Double-slit Experiment
- Square Root
- Brought to you by the letter G
- The Bernoulli Principle
- Purest Unobtainium
- I Smell Ozone
- Conveying a New Idea
- Upstream Downstream
- Give Me A V
- $eeing Dollar $ign$
- Doing Things The Hard Way
- Very Good
- Must I Do Everything For You?
- Now Stay Close To Me...
- ...But Not Too Close
- ...Not as I Do
- Do Try To Keep Up
- Whee Sports
- As you like it
This is actually a strange case where it looked bad because of the 29th
row, instead of the 30th row, and I had to change the 29th row instead of
the 30th row to fix it.
- Maze With No Entrance
- Ascending and Descending
- Mind The Gap
Same strange case as "As you like it" (it's the 29th row I had to change
that was the problem, not the 30th).
- 1950 Silverstone Grand V
- The Villi People
I found that Panic Room and The Final Challenge also looked strange behind the
roomname background, but I can't do much about either because towers' tile
data wrap around at the top and bottom, and if I added another row to either
it would be visible above the room name.
I've considered updating the development editors with these new level tiles,
but I decided against it as the development editors are already pretty
outdated anyway.
2020-02-03 22:24:30 +01:00
|
|
|
for (int j = 0; j < 31; j++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
for (int i = 0; i < 40; i++)
|
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
const int temp = map.tower.at(i, j, yoff);
|
|
|
|
if (temp > 0)
|
|
|
|
{
|
|
|
|
drawtile3(i * 8, (j * 8) - (yoff % 8), temp, towerbg.colstate);
|
|
|
|
}
|
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 Graphics::drawtowerspikes(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-04-30 21:58:08 +02:00
|
|
|
int spikeleveltop = lerp(map.oldspikeleveltop, map.spikeleveltop);
|
|
|
|
int spikelevelbottom = lerp(map.oldspikelevelbottom, map.spikelevelbottom);
|
2020-01-01 21:29:24 +01:00
|
|
|
for (int i = 0; i < 40; i++)
|
|
|
|
{
|
2020-11-03 00:05:24 +01:00
|
|
|
drawtile3(i * 8, -8+spikeleveltop, 9, towerbg.colstate);
|
|
|
|
drawtile3(i * 8, 230-spikelevelbottom, 8, towerbg.colstate, 8 - spikelevelbottom);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-03 00:05:24 +01:00
|
|
|
void Graphics::drawtowerbackground(const TowerBG& bg_obj)
|
2020-04-30 00:25:01 +02:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
clear();
|
|
|
|
|
|
|
|
const int offset = (int) lerp(0, -bg_obj.bscroll);
|
|
|
|
const SDL_Rect srcRect = {0, 8 + offset, SCREEN_WIDTH_PIXELS, SCREEN_HEIGHT_PIXELS};
|
|
|
|
|
|
|
|
copy_texture(bg_obj.texture, &srcRect, NULL);
|
2020-04-30 00:25:01 +02:00
|
|
|
}
|
|
|
|
|
2020-11-03 00:05:24 +01:00
|
|
|
void Graphics::updatetowerbackground(TowerBG& bg_obj)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-11-03 00:05:24 +01:00
|
|
|
if (bg_obj.bypos < 0) bg_obj.bypos += 120 * 8;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
SDL_Texture* target = SDL_GetRenderTarget(gameScreen.m_renderer);
|
|
|
|
set_render_target(bg_obj.texture);
|
|
|
|
|
2020-11-03 00:05:24 +01:00
|
|
|
if (bg_obj.tdrawback)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-11-03 00:05:24 +01:00
|
|
|
int off = bg_obj.scrolldir == 0 ? 0 : bg_obj.bscroll;
|
2020-01-01 21:29:24 +01:00
|
|
|
//Draw the whole thing; needed for every colour cycle!
|
2023-01-07 19:28:07 +01:00
|
|
|
clear();
|
2020-11-02 19:49:54 +01:00
|
|
|
for (int j = -1; j < 32; j++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
for (int i = 0; i < 40; i++)
|
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
const int temp = map.tower.backat(i, j, bg_obj.bypos);
|
2020-11-03 00:05:24 +01:00
|
|
|
drawtowertile3(i * 8, (j * 8) - (bg_obj.bypos % 8) - off, temp, bg_obj);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-03 00:05:24 +01:00
|
|
|
bg_obj.tdrawback = false;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
//just update the bottom
|
2023-03-04 01:02:53 +01:00
|
|
|
scroll_texture(bg_obj.texture, tempScrollingTexture, 0, -bg_obj.bscroll);
|
2020-11-03 00:05:24 +01:00
|
|
|
if (bg_obj.scrolldir == 0)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-04-29 23:28:11 +02:00
|
|
|
for (int i = 0; i < 40; i++)
|
2020-04-29 22:44:28 +02:00
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
int temp = map.tower.backat(i, -1, bg_obj.bypos);
|
2023-01-07 19:28:07 +01:00
|
|
|
drawtowertile3(i * 8, -1 * 8 - (bg_obj.bypos % 8), temp, bg_obj);
|
2020-11-03 00:05:24 +01:00
|
|
|
temp = map.tower.backat(i, 0, bg_obj.bypos);
|
|
|
|
drawtowertile3(i * 8, -(bg_obj.bypos % 8), temp, bg_obj);
|
2020-04-29 22:44:28 +02:00
|
|
|
}
|
2020-04-29 23:28:11 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
for (int i = 0; i < 40; i++)
|
2020-04-29 22:44:28 +02:00
|
|
|
{
|
2022-12-30 07:23:48 +01:00
|
|
|
int temp = map.tower.backat(i, 29, bg_obj.bypos);
|
2023-01-07 19:28:07 +01:00
|
|
|
drawtowertile3(i * 8, 29 * 8 - (bg_obj.bypos % 8) - bg_obj.bscroll, temp, bg_obj);
|
2020-11-03 00:05:24 +01:00
|
|
|
temp = map.tower.backat(i, 30, bg_obj.bypos);
|
2023-01-07 19:28:07 +01:00
|
|
|
drawtowertile3(i * 8, 30 * 8 - (bg_obj.bypos % 8) - bg_obj.bscroll, temp, bg_obj);
|
2020-11-03 00:05:24 +01:00
|
|
|
temp = map.tower.backat(i, 31, bg_obj.bypos);
|
2023-01-07 19:28:07 +01:00
|
|
|
drawtowertile3(i * 8, 31 * 8 - (bg_obj.bypos % 8) - bg_obj.bscroll, temp, bg_obj);
|
2020-11-03 00:05:24 +01:00
|
|
|
temp = map.tower.backat(i, 32, bg_obj.bypos);
|
2023-01-07 19:28:07 +01:00
|
|
|
drawtowertile3(i * 8, 32 * 8 - (bg_obj.bypos % 8) - bg_obj.bscroll, temp, bg_obj);
|
2020-04-29 22:44:28 +02:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
2023-01-07 19:28:07 +01:00
|
|
|
set_render_target(target);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2023-01-02 05:16:08 +01:00
|
|
|
SDL_Color Graphics::getcol( int t )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
//Setup predefinied colours as per our zany palette
|
|
|
|
switch(t)
|
|
|
|
{
|
|
|
|
//Player Normal
|
|
|
|
case 0:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(160 - help.glow/2 - (fRandom() * 20), 200 - help.glow/2, 220 - help.glow);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Player Hurt
|
|
|
|
case 1:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(196 - (fRandom() * 64), 10, 10);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Enemies and stuff
|
|
|
|
case 2:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(225 - (help.glow / 2), 75, 30);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 3: //Trinket
|
|
|
|
if (!trinketcolset)
|
|
|
|
{
|
|
|
|
trinketr = 200 - (fRandom() * 64);
|
|
|
|
trinketg = 200 - (fRandom() * 128);
|
|
|
|
trinketb = 164 + (fRandom() * 60);
|
|
|
|
trinketcolset = true;
|
|
|
|
}
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(trinketr, trinketg, trinketb);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 4: //Inactive savepoint
|
2022-12-30 07:23:48 +01:00
|
|
|
{
|
2023-01-02 01:36:43 +01:00
|
|
|
const int temp = (help.glow / 2) + (fRandom() * 8);
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(80 + temp, 80 + temp, 80 + temp);
|
2022-12-30 07:23:48 +01:00
|
|
|
}
|
2021-09-07 03:56:39 +02:00
|
|
|
case 5: //Active savepoint
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(164 + (fRandom() * 64), 164 + (fRandom() * 64), 255 - (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
case 6: //Enemy : Red
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(250 - help.glow/2, 60- help.glow/2, 60 - help.glow/2);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 7: //Enemy : Green
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(100 - help.glow/2 - (fRandom() * 30), 250 - help.glow/2, 100 - help.glow/2 - (fRandom() * 30));
|
2021-09-07 03:56:39 +02:00
|
|
|
case 8: //Enemy : Purple
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(250 - help.glow/2, 20, 128 - help.glow/2 + (fRandom() * 30));
|
2021-09-07 03:56:39 +02:00
|
|
|
case 9: //Enemy : Yellow
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(250 - help.glow/2, 250 - help.glow/2, 20);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 10: //Warp point (white)
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(255 - (fRandom() * 64), 255 - (fRandom() * 64), 255 - (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
case 11: //Enemy : Cyan
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(20, 250 - help.glow/2, 250 - help.glow/2);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 12: //Enemy : Blue
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(90 - help.glow/2, 90 - help.glow/2, 250 - help.glow/2);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Crew Members
|
|
|
|
//green
|
|
|
|
case 13:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(120 - help.glow/4 - (fRandom() * 20), 220 - help.glow/4, 120 - help.glow/4);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Yellow
|
|
|
|
case 14:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(220 - help.glow/4 - (fRandom() * 20), 210 - help.glow/4, 120 - help.glow/4);
|
2021-09-07 03:56:39 +02:00
|
|
|
//pink
|
|
|
|
case 15:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(255 - help.glow/8, 70 - help.glow/4, 70 - help.glow / 4);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Blue
|
|
|
|
case 16:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(75, 75, 255 - help.glow/4 - (fRandom() * 20));
|
2021-09-07 03:56:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
case 17: //Enemy : Orange
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(250 - help.glow/2, 130 - help.glow/2, 20);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 18: //Enemy : Gray
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(130 - help.glow/2, 130 - help.glow/2, 130 - help.glow/2);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 19: //Enemy : Dark gray
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(60 - help.glow/8, 60 - help.glow/8, 60 - help.glow/8);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Purple
|
|
|
|
case 20:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(220 - help.glow/4 - (fRandom() * 20), 120 - help.glow/4, 210 - help.glow/4);
|
2021-09-07 03:56:39 +02:00
|
|
|
|
|
|
|
case 21: //Enemy : Light Gray
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(180 - help.glow/2, 180 - help.glow/2, 180 - help.glow/2);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 22: //Enemy : Indicator Gray
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(230 - help.glow/2, 230- help.glow/2, 230 - help.glow/2);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 23: //Enemy : Indicator Gray
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(255 - help.glow/2 - (fRandom() * 40) , 255 - help.glow/2 - (fRandom() * 40), 255 - help.glow/2 - (fRandom() * 40));
|
2021-09-07 03:56:39 +02:00
|
|
|
|
|
|
|
//Trophies
|
Revert "Fix Secret Lab Time Trial trophies having wrong colors"
As reported by Dav999, Victoria and Vermilion's trophy colors are
swapped again in 2.4. He points to
37b7615b71c3a2f44e03c47894383107850812ff, the commit where I fixed the
color masks of every single surface to always be RGB or RGBA.
It sounded plausible to me, because it did have to do with colors, after
all. However, it didn't make sense to me, because I was like, I didn't
touch the trophy colors at all after I originally fixed them.
After I ruled out the RGBf() function as a confounder, I decided to see
whether intentionally reversing the color order in RGBf() to be BGR
would do anything, and to my surprise it actually swapped the colors
back around and it didn't actually look bad.
And then I realized: Swapping the trophy colors between RGB and BGR
ordering results in similar colors that still look good, but are simply
wrong, but not so wrong that they take on a color that no crewmate uses,
so it'd appear as if the crewmates were swapped, when in reality the
only thing that was swapped was actually the color order of the colors.
Trying to fix this by swapping the colors again, I actively confused
colors 33 and 35 (Vermilion and Victoria) with colors 32 and 34
(Vitellary and Viridian), so I was confused when Vermilion and Victoria
weren't swapping. Then as a debugging step, I only changed 34 to 32
without swapping 32 as well, and then finally noticed that I was
swapping Vitellary and Viridian, because there were now two Vitellarys.
And then I was reminded that Vitellary and Viridian were also wrongly
swapped since 2.0 as well.
And so then I finally realized: The original comments accompanying the
colors were correct after all. The only problem was that they were fed
into a function, RGBf(), that read the colors backwards, because the
codebase habitually changed the color order on a whim and it was really
hard to reason out which color order should be used at a given time, so
it ended up reading RGB colors as BGR, while it looked like it was
passing them through as-is.
So what happened was that in the first place, RGBf() was swapping RGB to
BGR. Then I came and swapped Vermilion and Victoria, and Vitellary and
Viridian around. Then later I fixed all the color masks, so RGBf()
stopped swapping RGB and BGR around. But then this ended up swapping the
colors of Vermilion and Victoria, and Vitellary and Viridian once again!
Therefore, swapping Vermilion and Victoria, and Vitellary and Viridian
was incorrect. Or at least, not the fix to the root cause. The root
cause would be to swap the colors in RGBf(), but this would be sort of
confusing to reason about - at least if I didn't bother to just type the
RGB values into an image editor. But that doesn't fix the real issue,
which is that the game kept swapping RGB and BGR around in every corner
of the codebase.
I further confirmed that there was no more RGB or BGR swapping by
deleting the plus-one-divide-by-three transformation in RGBf() and
seeing if the colors looked okay. Now with the colors being brighter, I
could see that passing it straight through looked fine, but
intentionally reversing it to be BGR resulted in colors that at a
distance looked okay, but were either washed out or too bright. At least
finally I could use my 8 years of playing this game for something.
So in conclusion, actually, 37b7615b71c3a2f44e03c47894383107850812ff
("Fix surface color masks") was the real fix, and
d271907f8c5d84308a3cf9323ac692199b8685a6 ("Fix Secret Lab Time Trial
trophies having wrong colors") was the real regression. It's just that
the regression came first, but it wasn't really a regression until I did
the other fix, so the fix isn't the regression, the regression is...
this is hurting my brain. Or the real regression was the friends we made
along the way, or something like that.
This is the most trivial bug ever caused by the technical debt of those
god-awful reversed color masks.
---
This reverts commit d271907f8c5d84308a3cf9323ac692199b8685a6.
Fixes #862.
2022-02-12 09:39:30 +01:00
|
|
|
//cyan
|
2021-09-07 03:56:39 +02:00
|
|
|
case 30:
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(160, 200, 220);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Purple
|
|
|
|
case 31:
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(220, 120, 210);
|
Revert "Fix Secret Lab Time Trial trophies having wrong colors"
As reported by Dav999, Victoria and Vermilion's trophy colors are
swapped again in 2.4. He points to
37b7615b71c3a2f44e03c47894383107850812ff, the commit where I fixed the
color masks of every single surface to always be RGB or RGBA.
It sounded plausible to me, because it did have to do with colors, after
all. However, it didn't make sense to me, because I was like, I didn't
touch the trophy colors at all after I originally fixed them.
After I ruled out the RGBf() function as a confounder, I decided to see
whether intentionally reversing the color order in RGBf() to be BGR
would do anything, and to my surprise it actually swapped the colors
back around and it didn't actually look bad.
And then I realized: Swapping the trophy colors between RGB and BGR
ordering results in similar colors that still look good, but are simply
wrong, but not so wrong that they take on a color that no crewmate uses,
so it'd appear as if the crewmates were swapped, when in reality the
only thing that was swapped was actually the color order of the colors.
Trying to fix this by swapping the colors again, I actively confused
colors 33 and 35 (Vermilion and Victoria) with colors 32 and 34
(Vitellary and Viridian), so I was confused when Vermilion and Victoria
weren't swapping. Then as a debugging step, I only changed 34 to 32
without swapping 32 as well, and then finally noticed that I was
swapping Vitellary and Viridian, because there were now two Vitellarys.
And then I was reminded that Vitellary and Viridian were also wrongly
swapped since 2.0 as well.
And so then I finally realized: The original comments accompanying the
colors were correct after all. The only problem was that they were fed
into a function, RGBf(), that read the colors backwards, because the
codebase habitually changed the color order on a whim and it was really
hard to reason out which color order should be used at a given time, so
it ended up reading RGB colors as BGR, while it looked like it was
passing them through as-is.
So what happened was that in the first place, RGBf() was swapping RGB to
BGR. Then I came and swapped Vermilion and Victoria, and Vitellary and
Viridian around. Then later I fixed all the color masks, so RGBf()
stopped swapping RGB and BGR around. But then this ended up swapping the
colors of Vermilion and Victoria, and Vitellary and Viridian once again!
Therefore, swapping Vermilion and Victoria, and Vitellary and Viridian
was incorrect. Or at least, not the fix to the root cause. The root
cause would be to swap the colors in RGBf(), but this would be sort of
confusing to reason about - at least if I didn't bother to just type the
RGB values into an image editor. But that doesn't fix the real issue,
which is that the game kept swapping RGB and BGR around in every corner
of the codebase.
I further confirmed that there was no more RGB or BGR swapping by
deleting the plus-one-divide-by-three transformation in RGBf() and
seeing if the colors looked okay. Now with the colors being brighter, I
could see that passing it straight through looked fine, but
intentionally reversing it to be BGR resulted in colors that at a
distance looked okay, but were either washed out or too bright. At least
finally I could use my 8 years of playing this game for something.
So in conclusion, actually, 37b7615b71c3a2f44e03c47894383107850812ff
("Fix surface color masks") was the real fix, and
d271907f8c5d84308a3cf9323ac692199b8685a6 ("Fix Secret Lab Time Trial
trophies having wrong colors") was the real regression. It's just that
the regression came first, but it wasn't really a regression until I did
the other fix, so the fix isn't the regression, the regression is...
this is hurting my brain. Or the real regression was the friends we made
along the way, or something like that.
This is the most trivial bug ever caused by the technical debt of those
god-awful reversed color masks.
---
This reverts commit d271907f8c5d84308a3cf9323ac692199b8685a6.
Fixes #862.
2022-02-12 09:39:30 +01:00
|
|
|
//Yellow
|
2021-09-07 03:56:39 +02:00
|
|
|
case 32:
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(220, 210, 120);
|
Revert "Fix Secret Lab Time Trial trophies having wrong colors"
As reported by Dav999, Victoria and Vermilion's trophy colors are
swapped again in 2.4. He points to
37b7615b71c3a2f44e03c47894383107850812ff, the commit where I fixed the
color masks of every single surface to always be RGB or RGBA.
It sounded plausible to me, because it did have to do with colors, after
all. However, it didn't make sense to me, because I was like, I didn't
touch the trophy colors at all after I originally fixed them.
After I ruled out the RGBf() function as a confounder, I decided to see
whether intentionally reversing the color order in RGBf() to be BGR
would do anything, and to my surprise it actually swapped the colors
back around and it didn't actually look bad.
And then I realized: Swapping the trophy colors between RGB and BGR
ordering results in similar colors that still look good, but are simply
wrong, but not so wrong that they take on a color that no crewmate uses,
so it'd appear as if the crewmates were swapped, when in reality the
only thing that was swapped was actually the color order of the colors.
Trying to fix this by swapping the colors again, I actively confused
colors 33 and 35 (Vermilion and Victoria) with colors 32 and 34
(Vitellary and Viridian), so I was confused when Vermilion and Victoria
weren't swapping. Then as a debugging step, I only changed 34 to 32
without swapping 32 as well, and then finally noticed that I was
swapping Vitellary and Viridian, because there were now two Vitellarys.
And then I was reminded that Vitellary and Viridian were also wrongly
swapped since 2.0 as well.
And so then I finally realized: The original comments accompanying the
colors were correct after all. The only problem was that they were fed
into a function, RGBf(), that read the colors backwards, because the
codebase habitually changed the color order on a whim and it was really
hard to reason out which color order should be used at a given time, so
it ended up reading RGB colors as BGR, while it looked like it was
passing them through as-is.
So what happened was that in the first place, RGBf() was swapping RGB to
BGR. Then I came and swapped Vermilion and Victoria, and Vitellary and
Viridian around. Then later I fixed all the color masks, so RGBf()
stopped swapping RGB and BGR around. But then this ended up swapping the
colors of Vermilion and Victoria, and Vitellary and Viridian once again!
Therefore, swapping Vermilion and Victoria, and Vitellary and Viridian
was incorrect. Or at least, not the fix to the root cause. The root
cause would be to swap the colors in RGBf(), but this would be sort of
confusing to reason about - at least if I didn't bother to just type the
RGB values into an image editor. But that doesn't fix the real issue,
which is that the game kept swapping RGB and BGR around in every corner
of the codebase.
I further confirmed that there was no more RGB or BGR swapping by
deleting the plus-one-divide-by-three transformation in RGBf() and
seeing if the colors looked okay. Now with the colors being brighter, I
could see that passing it straight through looked fine, but
intentionally reversing it to be BGR resulted in colors that at a
distance looked okay, but were either washed out or too bright. At least
finally I could use my 8 years of playing this game for something.
So in conclusion, actually, 37b7615b71c3a2f44e03c47894383107850812ff
("Fix surface color masks") was the real fix, and
d271907f8c5d84308a3cf9323ac692199b8685a6 ("Fix Secret Lab Time Trial
trophies having wrong colors") was the real regression. It's just that
the regression came first, but it wasn't really a regression until I did
the other fix, so the fix isn't the regression, the regression is...
this is hurting my brain. Or the real regression was the friends we made
along the way, or something like that.
This is the most trivial bug ever caused by the technical debt of those
god-awful reversed color masks.
---
This reverts commit d271907f8c5d84308a3cf9323ac692199b8685a6.
Fixes #862.
2022-02-12 09:39:30 +01:00
|
|
|
//red
|
2021-09-07 03:56:39 +02:00
|
|
|
case 33:
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(255, 70, 70);
|
2021-09-07 03:56:39 +02:00
|
|
|
//green
|
|
|
|
case 34:
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(120, 220, 120);
|
Revert "Fix Secret Lab Time Trial trophies having wrong colors"
As reported by Dav999, Victoria and Vermilion's trophy colors are
swapped again in 2.4. He points to
37b7615b71c3a2f44e03c47894383107850812ff, the commit where I fixed the
color masks of every single surface to always be RGB or RGBA.
It sounded plausible to me, because it did have to do with colors, after
all. However, it didn't make sense to me, because I was like, I didn't
touch the trophy colors at all after I originally fixed them.
After I ruled out the RGBf() function as a confounder, I decided to see
whether intentionally reversing the color order in RGBf() to be BGR
would do anything, and to my surprise it actually swapped the colors
back around and it didn't actually look bad.
And then I realized: Swapping the trophy colors between RGB and BGR
ordering results in similar colors that still look good, but are simply
wrong, but not so wrong that they take on a color that no crewmate uses,
so it'd appear as if the crewmates were swapped, when in reality the
only thing that was swapped was actually the color order of the colors.
Trying to fix this by swapping the colors again, I actively confused
colors 33 and 35 (Vermilion and Victoria) with colors 32 and 34
(Vitellary and Viridian), so I was confused when Vermilion and Victoria
weren't swapping. Then as a debugging step, I only changed 34 to 32
without swapping 32 as well, and then finally noticed that I was
swapping Vitellary and Viridian, because there were now two Vitellarys.
And then I was reminded that Vitellary and Viridian were also wrongly
swapped since 2.0 as well.
And so then I finally realized: The original comments accompanying the
colors were correct after all. The only problem was that they were fed
into a function, RGBf(), that read the colors backwards, because the
codebase habitually changed the color order on a whim and it was really
hard to reason out which color order should be used at a given time, so
it ended up reading RGB colors as BGR, while it looked like it was
passing them through as-is.
So what happened was that in the first place, RGBf() was swapping RGB to
BGR. Then I came and swapped Vermilion and Victoria, and Vitellary and
Viridian around. Then later I fixed all the color masks, so RGBf()
stopped swapping RGB and BGR around. But then this ended up swapping the
colors of Vermilion and Victoria, and Vitellary and Viridian once again!
Therefore, swapping Vermilion and Victoria, and Vitellary and Viridian
was incorrect. Or at least, not the fix to the root cause. The root
cause would be to swap the colors in RGBf(), but this would be sort of
confusing to reason about - at least if I didn't bother to just type the
RGB values into an image editor. But that doesn't fix the real issue,
which is that the game kept swapping RGB and BGR around in every corner
of the codebase.
I further confirmed that there was no more RGB or BGR swapping by
deleting the plus-one-divide-by-three transformation in RGBf() and
seeing if the colors looked okay. Now with the colors being brighter, I
could see that passing it straight through looked fine, but
intentionally reversing it to be BGR resulted in colors that at a
distance looked okay, but were either washed out or too bright. At least
finally I could use my 8 years of playing this game for something.
So in conclusion, actually, 37b7615b71c3a2f44e03c47894383107850812ff
("Fix surface color masks") was the real fix, and
d271907f8c5d84308a3cf9323ac692199b8685a6 ("Fix Secret Lab Time Trial
trophies having wrong colors") was the real regression. It's just that
the regression came first, but it wasn't really a regression until I did
the other fix, so the fix isn't the regression, the regression is...
this is hurting my brain. Or the real regression was the friends we made
along the way, or something like that.
This is the most trivial bug ever caused by the technical debt of those
god-awful reversed color masks.
---
This reverts commit d271907f8c5d84308a3cf9323ac692199b8685a6.
Fixes #862.
2022-02-12 09:39:30 +01:00
|
|
|
//Blue
|
2021-09-07 03:56:39 +02:00
|
|
|
case 35:
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(75, 75, 255);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Gold
|
|
|
|
case 36:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(180, 120, 20);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 37: //Trinket
|
|
|
|
if (!trinketcolset)
|
|
|
|
{
|
|
|
|
trinketr = 200 - (fRandom() * 64);
|
|
|
|
trinketg = 200 - (fRandom() * 128);
|
|
|
|
trinketb = 164 + (fRandom() * 60);
|
|
|
|
trinketcolset = true;
|
|
|
|
}
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(trinketr, trinketg, trinketb);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Silver
|
|
|
|
case 38:
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(196, 196, 196);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Bronze
|
|
|
|
case 39:
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(128, 64, 10);
|
2021-09-07 03:56:39 +02:00
|
|
|
//Awesome
|
|
|
|
case 40: //Teleporter in action!
|
2022-12-30 07:23:48 +01:00
|
|
|
{
|
|
|
|
const int temp = fRandom() * 150;
|
2021-09-07 03:56:39 +02:00
|
|
|
if(temp<33)
|
|
|
|
{
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(255 - (fRandom() * 64), 64 + (fRandom() * 64), 64 + (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
|
|
|
else if (temp < 66)
|
|
|
|
{
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(64 + (fRandom() * 64), 255 - (fRandom() * 64), 64 + (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
|
|
|
else if (temp < 100)
|
|
|
|
{
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(64 + (fRandom() * 64), 64 + (fRandom() * 64), 255 - (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-02 05:16:08 +01:00
|
|
|
return RGBf(164 + (fRandom() * 64), 164 + (fRandom() * 64), 255 - (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
2022-12-30 07:23:48 +01:00
|
|
|
}
|
2021-09-07 03:56:39 +02:00
|
|
|
|
|
|
|
case 100: //Inactive Teleporter
|
2022-12-30 07:23:48 +01:00
|
|
|
{
|
2023-01-02 01:36:43 +01:00
|
|
|
const int temp = (help.glow / 2) + (fRandom() * 8);
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(42 + temp, 42 + temp, 42 + temp);
|
2022-12-30 07:23:48 +01:00
|
|
|
}
|
2021-09-07 03:56:39 +02:00
|
|
|
case 101: //Active Teleporter
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(164 + (fRandom() * 64), 164 + (fRandom() * 64), 255 - (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
case 102: //Teleporter in action!
|
2022-12-30 07:23:48 +01:00
|
|
|
{
|
|
|
|
const int temp = fRandom() * 150;
|
2023-01-02 01:36:43 +01:00
|
|
|
if (temp < 33)
|
2021-09-07 03:56:39 +02:00
|
|
|
{
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(255 - (fRandom() * 64), 64 + (fRandom() * 64), 64 + (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
|
|
|
else if (temp < 66)
|
|
|
|
{
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(64 + (fRandom() * 64), 255 - (fRandom() * 64), 64 + (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
|
|
|
else if (temp < 100)
|
|
|
|
{
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(64 + (fRandom() * 64), 64 + (fRandom() * 64), 255 - (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(164 + (fRandom() * 64), 164 + (fRandom() * 64), 255 - (fRandom() * 64));
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
2022-12-30 07:23:48 +01:00
|
|
|
}
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
2023-01-02 05:16:08 +01:00
|
|
|
|
|
|
|
return getRGB(255, 255, 255);
|
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 Graphics::menuoffrender(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
if (copy_texture(gameplayTexture, NULL, NULL) != 0)
|
2021-09-07 03:56:39 +02:00
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
2020-04-30 23:42:08 +02:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
const int offset = (int) lerp(oldmenuoffset, menuoffset);
|
|
|
|
const SDL_Rect offsetRect = {0, offset, SCREEN_WIDTH_PIXELS, SCREEN_HEIGHT_PIXELS};
|
2020-04-30 23:42:08 +02:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
if (copy_texture(menuTexture, NULL, &offsetRect) != 0)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
2020-04-30 23:42:08 +02:00
|
|
|
}
|
|
|
|
|
2023-01-02 05:16:08 +01:00
|
|
|
SDL_Color Graphics::huetilegetcol(const int t)
|
2020-04-30 23:42:08 +02:00
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
switch (t)
|
|
|
|
{
|
|
|
|
case 0:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(250-int(fRandom()*32), 250-int(fRandom()*32), 10);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 1:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(250-int(fRandom()*32), 250-int(fRandom()*32), 10);
|
2021-09-07 03:56:39 +02:00
|
|
|
default:
|
2023-01-02 05:16:08 +01:00
|
|
|
return getRGB(250-int(fRandom()*32), 250-int(fRandom()*32), 10);
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2023-01-02 01:36:43 +01:00
|
|
|
SDL_Color Graphics::bigchunkygetcol(int t)
|
2020-04-30 23:57:21 +02:00
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
//A seperate index of colours, for simplicity
|
|
|
|
switch (t)
|
|
|
|
{
|
|
|
|
case 1:
|
2021-08-28 21:59:46 +02:00
|
|
|
return getRGB((fRandom() * 64), 10, 10);
|
2021-09-07 03:56:39 +02:00
|
|
|
case 2:
|
2021-08-28 21:59:46 +02:00
|
|
|
return getRGB(int(160- help.glow/2 - (fRandom()*20)), 200- help.glow/2, 220 - help.glow);
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
2023-01-02 01:36:43 +01:00
|
|
|
const SDL_Color color = {0, 0, 0, 0};
|
|
|
|
return color;
|
2020-04-30 23:57:21 +02: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 Graphics::textboxcenterx(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
2021-09-07 03:56:39 +02:00
|
|
|
{
|
|
|
|
vlog_error("textboxcenterx() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
2020-06-28 19:40:58 +02:00
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes[m].centerx();
|
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 Graphics::textboxwidth(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
2021-09-07 03:56:39 +02:00
|
|
|
{
|
|
|
|
vlog_error("textboxwidth() out-of-bounds!");
|
|
|
|
return 0;
|
|
|
|
}
|
2020-06-28 19:40:58 +02:00
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
return textboxes[m].w;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::textboxmoveto(int xo)
|
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
2021-09-07 03:56:39 +02:00
|
|
|
{
|
|
|
|
vlog_error("textboxmoveto() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
2020-06-28 19:40:58 +02:00
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes[m].xp = xo;
|
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 Graphics::textboxcentery(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-13 06:02:15 +02:00
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
2021-09-07 03:56:39 +02:00
|
|
|
{
|
|
|
|
vlog_error("textboxcentery() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
2020-06-28 19:40:58 +02:00
|
|
|
|
2021-09-13 06:02:15 +02:00
|
|
|
textboxes[m].centery();
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2022-12-30 22:57:24 +01:00
|
|
|
int Graphics::textboxwrap(int pad)
|
|
|
|
{
|
|
|
|
/* This function just takes a single-line textbox and wraps it...
|
|
|
|
* pad = the total number of characters we are going to pad this textbox.
|
|
|
|
* (or how many characters we should stay clear of 288 pixels width in general)
|
|
|
|
* Only to be used after a manual graphics.createtextbox[flipme] call.
|
|
|
|
* Returns the new, total height of the textbox. */
|
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
|
|
|
{
|
|
|
|
vlog_error("textboxwrap() out-of-bounds!");
|
|
|
|
return 16;
|
|
|
|
}
|
|
|
|
if (textboxes[m].lines.empty())
|
|
|
|
{
|
|
|
|
vlog_error("textboxwrap() has no first line!");
|
|
|
|
return 16;
|
|
|
|
}
|
2023-01-21 02:31:44 +01:00
|
|
|
std::string wrapped = font::string_wordwrap_balanced(
|
|
|
|
textboxes[m].print_flags,
|
|
|
|
textboxes[m].lines[0],
|
|
|
|
36*8 - pad*8
|
|
|
|
);
|
2022-12-30 22:57:24 +01:00
|
|
|
textboxes[m].lines.clear();
|
|
|
|
|
|
|
|
size_t startline = 0;
|
|
|
|
size_t newline;
|
|
|
|
do {
|
|
|
|
size_t pos_n = wrapped.find('\n', startline);
|
|
|
|
size_t pos_p = wrapped.find('|', startline);
|
|
|
|
newline = SDL_min(pos_n, pos_p);
|
|
|
|
addline(wrapped.substr(startline, newline-startline));
|
|
|
|
startline = newline+1;
|
|
|
|
} while (newline != std::string::npos);
|
|
|
|
|
|
|
|
return textboxes[m].h;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::textboxpad(size_t left_pad, size_t right_pad)
|
|
|
|
{
|
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
|
|
|
{
|
|
|
|
vlog_error("textboxpad() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
textboxes[m].pad(left_pad, right_pad);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::textboxpadtowidth(size_t new_w)
|
|
|
|
{
|
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
|
|
|
{
|
|
|
|
vlog_error("textboxpadtowidth() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
textboxes[m].padtowidth(new_w);
|
|
|
|
}
|
|
|
|
|
2023-03-18 23:24:14 +01:00
|
|
|
void Graphics::textboxcentertext(void)
|
2022-12-30 22:57:24 +01:00
|
|
|
{
|
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
|
|
|
{
|
|
|
|
vlog_error("textboxcentertext() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
textboxes[m].centertext();
|
|
|
|
}
|
|
|
|
|
2023-01-13 05:11:39 +01:00
|
|
|
void Graphics::textboxprintflags(const uint32_t flags)
|
|
|
|
{
|
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
|
|
|
{
|
|
|
|
vlog_error("textboxprintflags() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
textboxes[m].print_flags = flags;
|
|
|
|
textboxes[m].resize();
|
|
|
|
}
|
|
|
|
|
2023-03-18 23:24:14 +01:00
|
|
|
void Graphics::textboxcommsrelay(void)
|
2022-12-30 22:57:24 +01:00
|
|
|
{
|
|
|
|
/* Special treatment for the gamestate textboxes in Comms Relay */
|
|
|
|
if (!INBOUNDS_VEC(m, textboxes))
|
|
|
|
{
|
|
|
|
vlog_error("textboxcommsrelay() out-of-bounds!");
|
|
|
|
return;
|
|
|
|
}
|
2023-01-13 05:11:39 +01:00
|
|
|
textboxprintflags(PR_FONT_INTERFACE);
|
2022-12-30 22:57:24 +01:00
|
|
|
textboxwrap(11);
|
|
|
|
textboxes[m].xp = 224 - textboxes[m].w;
|
|
|
|
}
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
int Graphics::crewcolour(const int t)
|
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
//given crewmate t, return colour in setcol
|
|
|
|
if (t == 0) return CYAN;
|
|
|
|
if (t == 1) return PURPLE;
|
|
|
|
if (t == 2) return YELLOW;
|
|
|
|
if (t == 3) return RED;
|
|
|
|
if (t == 4) return GREEN;
|
|
|
|
if (t == 5) return BLUE;
|
|
|
|
return 0;
|
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 Graphics::flashlight(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
set_blendmode(SDL_BLENDMODE_NONE);
|
|
|
|
|
|
|
|
fill_rect(0xBB, 0xBB, 0xBB, 0xBB);
|
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 Graphics::screenshake(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
if (gameScreen.badSignalEffect)
|
|
|
|
{
|
2023-03-04 23:02:47 +01:00
|
|
|
ApplyFilter(tempFilterSrc, tempFilterDest);
|
2023-01-07 19:28:07 +01:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-03-04 00:25:15 +01:00
|
|
|
set_render_target(menuoffTexture);
|
2023-01-07 19:28:07 +01:00
|
|
|
set_blendmode(SDL_BLENDMODE_NONE);
|
|
|
|
clear();
|
|
|
|
|
|
|
|
const SDL_Rect shake = {screenshake_x, screenshake_y, SCREEN_WIDTH_PIXELS, SCREEN_HEIGHT_PIXELS};
|
|
|
|
|
|
|
|
copy_texture(gameTexture, NULL, &shake);
|
|
|
|
|
|
|
|
set_render_target(gameTexture);
|
|
|
|
clear();
|
|
|
|
|
2023-01-29 02:34:33 +01:00
|
|
|
// Clear the gameplay texture so blackout() is actually black after a screenshake
|
Fix the game texture clearing during menu shaking
Because of how `blackout` works, screen shaking must clear the gameplay
buffer. `blackout` simply pauses rendering, so if the gameplay buffer
gets cleared, then the screen will just be black, otherwise it'll look
like the game is "frozen". VVVVVV only uses `blackout` during screen
shaking, so it works as intended. However, when reimplementing this
behavior in the move to using the SDL_Renderer system, I failed to
notice that since my implementation always clears the gameplay buffer
when shaking, if you open the menu during a shake, instead of seeing
gameplay during the transition animation, you only see black. This has
been fixed with a simple `game.blackout` check before clearing the
gameplay buffer.
2023-03-18 21:36:07 +01:00
|
|
|
if (game.gamestate == GAMEMODE && game.blackout)
|
2023-01-29 02:34:33 +01:00
|
|
|
{
|
|
|
|
set_render_target(gameplayTexture);
|
|
|
|
clear();
|
|
|
|
}
|
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
set_render_target(NULL);
|
2023-02-15 00:24:37 +01:00
|
|
|
set_blendmode(SDL_BLENDMODE_NONE);
|
|
|
|
clear();
|
|
|
|
|
2023-03-04 00:25:15 +01:00
|
|
|
copy_texture(menuoffTexture, NULL, NULL, 0, NULL, flipmode ? SDL_FLIP_VERTICAL : SDL_FLIP_NONE);
|
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 Graphics::updatescreenshake(void)
|
2020-04-29 02:29:59 +02:00
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
screenshake_x = static_cast<Sint32>((fRandom() * 7) - 4);
|
|
|
|
screenshake_y = static_cast<Sint32>((fRandom() * 7) - 4);
|
2020-04-29 02:29:59 +02: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 Graphics::render(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
if (gameScreen.badSignalEffect)
|
|
|
|
{
|
2023-03-04 23:02:47 +01:00
|
|
|
ApplyFilter(tempFilterSrc, tempFilterDest);
|
2023-01-07 19:28:07 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
set_render_target(NULL);
|
|
|
|
set_blendmode(SDL_BLENDMODE_NONE);
|
|
|
|
clear();
|
|
|
|
|
|
|
|
copy_texture(gameTexture, NULL, NULL, 0, NULL, flipmode ? SDL_FLIP_VERTICAL : SDL_FLIP_NONE);
|
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 Graphics::renderwithscreeneffects(void)
|
2020-04-27 04:24:50 +02:00
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
if (game.flashlight > 0 && !game.noflashingmode)
|
|
|
|
{
|
|
|
|
flashlight();
|
|
|
|
}
|
2020-04-27 04:24:50 +02:00
|
|
|
|
2021-09-07 03:56:39 +02:00
|
|
|
if (game.screenshake > 0 && !game.noflashingmode)
|
|
|
|
{
|
|
|
|
screenshake();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
render();
|
|
|
|
}
|
2020-04-27 04:24:50 +02:00
|
|
|
}
|
|
|
|
|
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 Graphics::renderfixedpre(void)
|
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
if (game.screenshake > 0)
|
|
|
|
{
|
|
|
|
updatescreenshake();
|
|
|
|
}
|
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
|
|
|
|
Extern `gameScreen`, remove `screenbuffer`
I know earlier I removed the gameScreen extern in favor of using
screenbuffer, but that was only to be consistent. After further
consideration, I have found that it's actually really stupid.
There's no reason to be accessing it through screenbuffer, and it's
probably an artifact of 2.0-2.2 passing stack-allocated otherwise-global
classes everywhere through function arguments. Also, it leads to stupid
bugs where screenbuffer could potentially be NULL, which has already
resulted in various annoying crashes in the past. Although those could
be fixed by simply initializing screenbuffer at the very top of main(),
but, why not just scrap the whole thing anyway?
So that's what I'm doing.
As a nice side effect, I've removed the transitive include of Screen.h
from Graphics.h. This could've been done already since it only includes
it for the pointer anyway, but it's still good to do it now.
2021-12-25 08:56:47 +01:00
|
|
|
if (gameScreen.badSignalEffect)
|
2021-09-07 03:56:39 +02:00
|
|
|
{
|
|
|
|
UpdateFilter();
|
|
|
|
}
|
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 Graphics::renderfixedpost(void)
|
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
/* Screen effects timers */
|
|
|
|
if (game.flashlight > 0)
|
|
|
|
{
|
|
|
|
--game.flashlight;
|
|
|
|
}
|
|
|
|
if (game.screenshake > 0)
|
|
|
|
{
|
|
|
|
--game.screenshake;
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2023-01-02 01:36:43 +01:00
|
|
|
void Graphics::drawtele(int x, int y, int t, const SDL_Color color)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
SDL_Rect telerect;
|
2023-01-07 19:28:07 +01:00
|
|
|
setRect(telerect, x, y, tele_rect.w, tele_rect.h);
|
|
|
|
|
|
|
|
draw_grid_tile(grphx.im_teleporter, 0, x, y, tele_rect.w, tele_rect.h, 16, 16, 16);
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2021-09-07 03:56:39 +02:00
|
|
|
if (t > 9) t = 8;
|
|
|
|
if (t < 1) t = 1;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_teleporter, t, x, y, tele_rect.w, tele_rect.h, color);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2023-01-02 01:36:43 +01:00
|
|
|
SDL_Color Graphics::getRGBA(const Uint8 r, const Uint8 g, const Uint8 b, const Uint8 a)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-02 01:36:43 +01:00
|
|
|
const SDL_Color color = {r, g, b, a};
|
|
|
|
return color;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2023-01-02 01:36:43 +01:00
|
|
|
SDL_Color Graphics::getRGB(const Uint8 r, const Uint8 g, const Uint8 b)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-02 01:36:43 +01:00
|
|
|
const SDL_Color color = {r, g, b, 255};
|
|
|
|
return color;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
2023-01-02 01:36:43 +01:00
|
|
|
SDL_Color Graphics::RGBf(int r, int g, int b)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2023-01-02 01:36:43 +01:00
|
|
|
r = (r + 128) / 3;
|
|
|
|
g = (g + 128) / 3;
|
|
|
|
b = (b + 128) / 3;
|
|
|
|
const SDL_Color color = {(Uint8) r, (Uint8) g, (Uint8) b, 255};
|
|
|
|
return color;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::drawforetile(int x, int y, int t)
|
|
|
|
{
|
2020-06-30 20:47:22 +02:00
|
|
|
#if !defined(NO_CUSTOM_LEVELS)
|
2021-09-07 03:56:39 +02:00
|
|
|
if (shouldrecoloroneway(t, tiles1_mounted))
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_tiles_tint, t, x, y, tiles_rect.w, tiles_rect.h, cl.getonewaycol());
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
|
|
|
else
|
2020-06-30 20:47:22 +02:00
|
|
|
#endif
|
2021-09-07 03:56:39 +02:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_tiles, t, x, y, tiles_rect.w, tiles_rect.h);
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::drawforetile2(int x, int y, int t)
|
|
|
|
{
|
2020-06-30 20:47:22 +02:00
|
|
|
#if !defined(NO_CUSTOM_LEVELS)
|
2021-09-07 03:56:39 +02:00
|
|
|
if (shouldrecoloroneway(t, tiles2_mounted))
|
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_tiles2_tint, t, x, y, tiles_rect.w, tiles_rect.h, cl.getonewaycol());
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
|
|
|
else
|
2020-06-30 20:47:22 +02:00
|
|
|
#endif
|
2021-09-07 03:56:39 +02:00
|
|
|
{
|
2023-01-07 19:28:07 +01:00
|
|
|
draw_grid_tile(grphx.im_tiles2, t, x, y, tiles_rect.w, tiles_rect.h);
|
2021-09-07 03:56:39 +02:00
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::drawforetile3(int x, int y, int t, int off)
|
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
t += off * 30;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
draw_grid_tile(grphx.im_tiles3, t, x, y, tiles_rect.w, tiles_rect.h);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void Graphics::drawrect(int x, int y, int w, int h, int r, int g, int b)
|
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
SDL_Rect madrect;
|
|
|
|
//Draw the retangle indicated by that object
|
|
|
|
madrect.x = x;
|
|
|
|
madrect.y = y;
|
|
|
|
madrect.w = w;
|
|
|
|
madrect.h = 1;
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&madrect, getRGB(r, g, b));
|
2021-09-07 03:56:39 +02:00
|
|
|
|
|
|
|
madrect.w = 1;
|
|
|
|
madrect.h = h;
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&madrect, getRGB(r, g, b));
|
2021-09-07 03:56:39 +02:00
|
|
|
|
|
|
|
madrect.x = x + w - 1;
|
|
|
|
madrect.w = 1;
|
|
|
|
madrect.h = h;
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&madrect, getRGB(r, g, b));
|
2021-09-07 03:56:39 +02:00
|
|
|
madrect.x = x;
|
|
|
|
madrect.y = y + h - 1;
|
|
|
|
madrect.w = w;
|
|
|
|
madrect.h = 1;
|
2023-01-07 19:28:07 +01:00
|
|
|
fill_rect(&madrect, getRGB(r, g, b));
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
bool Graphics::onscreen(int t)
|
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
return (t >= -40 && t <= 280);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-06-01 01:31:02 +02:00
|
|
|
|
2021-08-07 05:57:34 +02:00
|
|
|
bool Graphics::reloadresources(void)
|
2021-02-16 00:38:41 +01:00
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
grphx.destroy();
|
|
|
|
grphx.init();
|
2020-06-12 02:55:27 +02:00
|
|
|
|
2021-09-07 03:56:39 +02:00
|
|
|
destroy();
|
2020-06-12 02:55:27 +02:00
|
|
|
|
2021-09-07 03:56:39 +02:00
|
|
|
MAYBE_FAIL(MakeSpriteArray());
|
2020-06-12 02:55:27 +02:00
|
|
|
|
2023-01-07 19:28:07 +01:00
|
|
|
images[IMAGE_LEVELCOMPLETE] = grphx.im_image0;
|
|
|
|
images[IMAGE_MINIMAP] = grphx.im_image1;
|
|
|
|
images[IMAGE_COVERED] = grphx.im_image2;
|
|
|
|
images[IMAGE_ELEPHANT] = grphx.im_image3;
|
|
|
|
images[IMAGE_GAMECOMPLETE] = grphx.im_image4;
|
|
|
|
images[IMAGE_FLIPLEVELCOMPLETE] = grphx.im_image5;
|
|
|
|
images[IMAGE_FLIPGAMECOMPLETE] = grphx.im_image6;
|
|
|
|
|
|
|
|
images[IMAGE_SITE] = grphx.im_image7;
|
|
|
|
images[IMAGE_SITE2] = grphx.im_image8;
|
|
|
|
images[IMAGE_SITE3] = grphx.im_image9;
|
|
|
|
images[IMAGE_ENDING] = grphx.im_image10;
|
|
|
|
images[IMAGE_SITE4] = grphx.im_image11;
|
|
|
|
images[IMAGE_CUSTOMMINIMAP] = grphx.im_image12;
|
2020-06-12 02:55:27 +02:00
|
|
|
|
Extern `gameScreen`, remove `screenbuffer`
I know earlier I removed the gameScreen extern in favor of using
screenbuffer, but that was only to be consistent. After further
consideration, I have found that it's actually really stupid.
There's no reason to be accessing it through screenbuffer, and it's
probably an artifact of 2.0-2.2 passing stack-allocated otherwise-global
classes everywhere through function arguments. Also, it leads to stupid
bugs where screenbuffer could potentially be NULL, which has already
resulted in various annoying crashes in the past. Although those could
be fixed by simply initializing screenbuffer at the very top of main(),
but, why not just scrap the whole thing anyway?
So that's what I'm doing.
As a nice side effect, I've removed the transitive include of Screen.h
from Graphics.h. This could've been done already since it only includes
it for the pointer anyway, but it's still good to do it now.
2021-12-25 08:56:47 +01:00
|
|
|
gameScreen.LoadIcon();
|
2020-11-01 04:30:24 +01:00
|
|
|
|
2021-09-07 03:56:39 +02:00
|
|
|
music.destroy();
|
|
|
|
music.init();
|
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
|
2021-09-07 03:56:39 +02:00
|
|
|
tiles1_mounted = FILESYSTEM_isAssetMounted("graphics/tiles.png");
|
|
|
|
tiles2_mounted = FILESYSTEM_isAssetMounted("graphics/tiles2.png");
|
|
|
|
minimap_mounted = FILESYSTEM_isAssetMounted("graphics/minimap.png");
|
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
|
2021-08-07 05:57:34 +02:00
|
|
|
|
2022-12-30 22:57:24 +01:00
|
|
|
gamecomplete_mounted = FILESYSTEM_isAssetMounted("graphics/gamecomplete.png");
|
|
|
|
levelcomplete_mounted = FILESYSTEM_isAssetMounted("graphics/levelcomplete.png");
|
|
|
|
flipgamecomplete_mounted = FILESYSTEM_isAssetMounted("graphics/flipgamecomplete.png");
|
|
|
|
fliplevelcomplete_mounted = FILESYSTEM_isAssetMounted("graphics/fliplevelcomplete.png");
|
|
|
|
|
2021-09-07 03:56:39 +02:00
|
|
|
return true;
|
2021-08-07 05:57:34 +02:00
|
|
|
|
|
|
|
fail:
|
2021-09-07 03:56:39 +02:00
|
|
|
return false;
|
2020-06-01 01:31:02 +02:00
|
|
|
}
|
2020-05-02 22:53:19 +02:00
|
|
|
|
2023-01-02 01:36:43 +01:00
|
|
|
SDL_Color Graphics::crewcolourreal(int t)
|
2020-05-02 22:53:19 +02:00
|
|
|
{
|
2021-09-07 03:56:39 +02:00
|
|
|
switch (t)
|
|
|
|
{
|
|
|
|
case 0:
|
|
|
|
return col_crewcyan;
|
|
|
|
case 1:
|
|
|
|
return col_crewpurple;
|
|
|
|
case 2:
|
|
|
|
return col_crewyellow;
|
|
|
|
case 3:
|
|
|
|
return col_crewred;
|
|
|
|
case 4:
|
|
|
|
return col_crewgreen;
|
|
|
|
case 5:
|
|
|
|
return col_crewblue;
|
|
|
|
}
|
|
|
|
return col_crewcyan;
|
2020-05-02 22:53:19 +02:00
|
|
|
}
|
2022-12-30 22:57:24 +01:00
|
|
|
|
2023-01-13 05:11:39 +01:00
|
|
|
void Graphics::render_roomname(uint32_t font_flag, const char* roomname, int r, int g, int b)
|
2022-12-30 22:57:24 +01:00
|
|
|
{
|
2023-01-13 05:11:39 +01:00
|
|
|
int font_height = font::height(font_flag);
|
2023-01-12 05:27:52 +01:00
|
|
|
if (font_height <= 8)
|
|
|
|
{
|
|
|
|
footerrect.h = font_height + 2;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
footerrect.h = font_height + 1;
|
|
|
|
}
|
|
|
|
footerrect.y = 240 - footerrect.h;
|
2023-01-07 19:28:07 +01:00
|
|
|
|
|
|
|
set_blendmode(SDL_BLENDMODE_BLEND);
|
|
|
|
fill_rect(&footerrect, getRGBA(0, 0, 0, translucentroomname ? 127 : 255));
|
2023-01-13 05:11:39 +01:00
|
|
|
font::print(font_flag | PR_CEN | PR_BOR | PR_CJK_LOW, -1, footerrect.y+1, roomname, r, g, b);
|
2023-01-07 19:28:07 +01:00
|
|
|
set_blendmode(SDL_BLENDMODE_NONE);
|
2022-12-30 22:57:24 +01:00
|
|
|
}
|