Every now and then, the game crashes for me because of a division by
zero, due to the rect returned by `Graphics::get_stretch_info`. I don't
fully know how the width and height get set to 0, but this should
protect against it.
As I always use integer scaling, my guess is that
`Screen::GetScreenSize` (which later calls `SDL_GetRendererOutputSize`)
returns 0 sometimes, and the code trusts that -- but I know that
windows and things can be finicky, so the clamp is probably a good
idea.
When `SDL_RenderReadPixels` fails for some reason, the game tries to
free the temporary source surface it creates. Unfortunately, it never
sets it to `NULL` after, so the next time the game tries to render the
filter, it'll try to work with a memory region that was already freed.
To fix this, I just replaced `SDL_FreeSurface(*src);` with
`VVV_freefunc(SDL_FreeSurface, *src);` which is a helper macro which
sets the pointer to NULL after freeing.
Now, there's a new issue -- since the temporary buffer is now NULL,
next frame we'll try to remake it! So I've introduced a static bool
which disables the filter entirely if `SDL_RenderReadPixels` fails.
Without this, it'd create and destroy a surface every frame, which
could lead to slowdown. (Not as slow as the filter when it DOES work,
but still...)
I also added a line which frees the second temporary surface... it's
weird that was missing in the first place, but I think reimplementing
analogue mode was one of the last things I did for the renderer
rewrite anyways.
Resolves#1223.
PR #1226 tweaks both the crew and the stats screens. When there's no
trinkets in the level, it removes the trinket count from the STATS
screen in the menu. This, however, is missing a `custommode` check,
meaning that the main game is ALSO missing the trinket count.
This PR fixes that oversight.
There's a problem in #1224 where it breaks spawning custom activity
zones. After a bit of confusion after this was reported, I realized
that I removed the fallback from `getcrewman` and changed the return
value to `-1` if the entity isn't found, to avoid returning the wrong
entity (entity 0, aka probably the player).
Unfortunately, it seems like a ton of levels (including my older ones)
rely on this behavior.
Creating custom activity zones is a long process which uses a bunch of
unintended behaviour, which includes targeting a crewmate with color
35. With the change I mentioned earlier, the `getcrewman` function
would return `-1` instead, which was out of bounds of the entity array,
so the game avoided spawning the activity zone at all. The prior
behaviour of falling back to entity 0 (most likely the player) would
spawn the activity zone around the player instead.
Nowadays, I try to spawn a crewmate with color 35 anyways so I can
control where the box spawns (instead of on the player always), however
most people don't (and haven't) so reverting this change seems best for
now.
If we wanted to reintroduce the `-1` fallback in the future, things
that call `getcrewman` would have to check for `-1` and use `0`
instead, but that would require a lot more testing and studying where
it's used, and I'd rather squash this bug quickly and worry about
cleanliness later.
Entity colors are just integers. Their colour ID gets passed through a
big switch, returning different RGB values depending on the colour ID
(and can also get affected by randomness or other game state.)
But because of this, there's a bunch of random numbers floating around,
with no actual description on what they are other than comments which,
while most of the time are accurate, only exist in the switch.
To fix this, this commit adds a new enum which labels every colour.
While we can't use it as a type (as we need to allow colours outside of
what are defined, in case people want a "pure white", and scripting can
set any colour ID they want), colours have to stay as `int`.
This PR adds a new XML property for the player's colour. It is 0 by
default, but you can change it to any colour ID. For example, making
the player use the trinket color is `<PlayerColour>3</PlayerColour>`.
This is mostly a quality-of-life addition, as the player's colour is
always 0 unless changed by scripts. A lot of levels which use different
player colours use an intro script which both changes the player's
colour and sets their respawn colour, which works great for finished,
completed levels, but makes playtesting a little more annoying as they
will spawn in as the wrong colour. Adding a level property for the
default player colour fixes this annoyance.
Additionally, this changes the behavior of `restoreplayercolour`. This
command used to set the player's colour to 0 (ignoring the respawn
colour, so when Viridian would die, they would revert to the respawn
colour). Now, it sets both Viridian's colour AND the respawn colour to
what was present in the level file. This way, you can temporarily
change the player colour using the script commands, and then use
`restoreplayercolour` to revert back to what the player colour
normally is.
The start point colour has also changed, to show the player colour
instead of always colour 0.
Like most changes like this, a way to change this in-editor does not
yet exist, but is planned for the future.
Turns out there was a little miscommunication with the translator -
they said the option needed to say "Ślōnsko" but were only talking
about correcting the first word, where I thought the whole thing needed
to be replaced.
If you push a button to set a controller binding, you may either hear
one Viridian squeak, two Viridian squeaks (a louder one), or Viridian
doesn't stop squeaking until you let go of the button. While you hear
the continuous squeaking, your save file is also repeatedly saved.
There are two small bugs at play here:
- the squeak is actually played in two different places at the same
time (both in titleinput() whenever a button is pressed, and in
updatebuttonmappings() when a mapping is succesfully changed)
- titleinput() doesn't register that a button is held down and applies
the button (and saves to file) every frame for as long as the button
is held
This commit fixes both these issues. Now a single button press always
causes one squeak, and only if the bindings actually changed. Your save
file is also no longer saved repeatedly from holding down the button.
In an effort to remove magic numbers, I've given every entity type a
name. Hopefully I didn't miss anywhere.
Also, add `createentity` case 100 for backwards compatibility.
Co-authored-by: NyakoFox <nyakowofox@gmail.com>
Co-authored-by: Dav999 <dav999.tolp@gmail.com>
This argument forces the textbox position, meaning it won't be moved
to be inside of the bounds of the screen (nor have the 10 pixel padding
on each side.)
This replaces all instances of unlocking all rooms on the map with calls
to map.fullmap(), for consistency.
This also fixes two comments that got swapped around in startgamemode().
I don't know how that happened.
[skip ci]
Some discussion on the Discord server resulted in this change. It's a
quality-of-life improvement where, if the game is in slowdown mode, it
will return to 100% speed for the duration of the death animation.
The reasoning is obvious. There is nothing to do during the death
animation, so making it take longer during slowdown is just an annoyance
to the player, almost a penalty for them using an accessibility option.
This is the same reason why slowdown no longer applies in menus, etc.
This makes it so that it is possible to obtain the Master of the
Universe trophy/achievement, usually unlocked by beating No Death Mode,
outside of NDM.
There are several conditions that need to be met:
1. The game needs to be started from a new game and cannot be from
loading a save.
2. Accessibility modes (invincibility and slowdown) must never be
enabled.
If either condition is violated, then the boolean that keeps track of
NDM eligibility will be set to false.
Currently, you can change platform speed, but not enemy speed, which is
always hardcoded to be 4. This commit fixes that, by adding the
"enemyv" property, which is an offset to the speed of 4. Since it
defaults to 0, older levels are not broken by this change.
Just extending the selection background left by one pixel so there's
not one pixel of black background to the left of a selection that
starts at the beginning of the text, and so some characters being
selected show up better (particularly where there's a long vertical bar
at the first pixel). We shouldn't be overlapping any part of the
previous character, since every character normally has a pixel of
spacing on the right.
Decided to implement it anyway since the broken behavior (selection
length always being 0, at least on Windows) may get fixed later in SDL,
so let's do it right in one go.
This shows the uncommitted text in a box in the bottom left corner.
This doesn't show the selection (defined by the start and length fields
in the event) yet, but this is already much better than it was on its
own, and I don't know how urgent the selection is since it's broken on
Windows anyway.
When inputting uncommitted text from an IME, this is now stored in a
std::string imebuffer, just like keybuffer. It also enables extended
editing events, so text longer than what fits in the standard editing
event is also supported. This commit does not yet display the text
onscreen.
This fixes a regression from 2.3. Consider the following diagram:
CC
X CC
<<<<
"C" indicates one tile of a checkpoint entity, "X" indicates a spike
tile, and "<" indicates one tile of a conveyor entity that has the
default speed (4 pixels per frame) going leftwards.
Now consider if the player were to touch the checkpoint and die. In 2.2,
they would be able to escape from the spike by holding right. But in
2.3, they would not be able to, and would die from the spike
continuously with no escape.
This happens because in 2.2, the player would spawn a couple pixels off
the surface, and this gained them an extra frame of movement to move
away from the conveyor. 2.3 places the player directly on the ground,
moving them one frame earlier and thus forcing them to their doom.
Now consider the following diagram:
CC
X CC
<<<<
The difference with the previous diagram is that this time, the spike is
one tile closer. This time, there is no escape in 2.2 and you will
always die no matter what.
By the way, both diagrams have the same behavior if the conveyor is
rightwards and if everything is flipped upside-down. Thankfully, it
doesn't seem to be direction-dependent.
The reason 2.3 lowered the player onto the surface was for consistency
(see PR #502), and I don't want to undo that. So I think the best
solution here is to re-add the extra frame of control by conveyors only
moving the player after lifeseq has advanced enough.
