This removes the magic numbers used for `animate`, and makes the
animation system far more flexible, instead giving entities the option
to control what they need, instead of having a bunch of duplicated
hardly-readable code.
So, the radar enemy type was originally 16x16. I meant to change it to
something that made more sense, but I messed up and made it 32x32
instead of 64x64 like it is visually.
While the last commit was an attempt at making colors be set better,
this one should help more. Basically, things that emitters emit now
copy the emitter's color. That means, if you change the color of the
emitter, what it emits will change as well. This means we don't have
to worry about setting the colour ourselves, just the enemy type.
`set_enemy_colour` is now called BEFORE setting the type, so the type's
color will override the room color. This is what we want -- in the
future there might be custom enemy types, and if you specify a specific
color, you probably want that color to be used.
But wait, don't the types usable in levels have their colors set? Well,
this commit also duplicates the editor enemy types and sets their
colors to `-1` so they'll use the room's color instead, or more
accurately, they'll use the color they had previously, which was the
room's enemy color.
With this system, old levels which use main game enemies will have the
correct colors -- the colors stored in their enemy types. And if it
becomes possible to make custom enemy types, if someone makes an
emitter which uses the room's color (by passing in color `-1`), the
enemies which it emits will use the room's color as well, since it will
copy what the emitter itself uses.
All of that just to say: colors are now handled a bit more sanely.
There's a few cases in `setenemyroom` which are only meant to override
the enemy colour set in the type, so let's move that to it's own
function instead. While we're at it, we should move the custom level
enemy color logic there as well, because it's in an awkward place.
This will also help with things like custom enemy types in the future,
or using things like the emitters in custom levels, because this will
correct those colors in custom levels.
Emitters are odd. They rely on `setenemy` to set the right type of the
entities they emit. However, `setenemy` only gets called in specific
rooms, so if you use these enemy types outside of those rooms, they'd
just infinitely spawn themselves and, well, that's a memory leak.
The prior fix for this was simply not allowing emitter types outside
of those rooms. This, however, feels very hacky and is a little
disappointing as well.
This commit improves emitters by no longer relying on `setenemy`, and
instead setting the emitted enemy type ourselves. However, `setenemy`
still happens, and to make sure we don't set the enemy type *twice*,
we set the `para` attribute of the spawned enemies to `-1`, so that
`setenemy` will not do anything at all to the spawned enemy.
The reason I don't remove the code in `setenemy` outright is a couple
things:
- The main game code still relies on it for spawning the initial
enemies in the room
- Custom levels may rely on the prior behavior (sadly)
This commit cleans up setting enemy properties. It deduplicates code,
makes custom levels spawn enemies better (doesn't just pretend it's a
certain main game room to set the settings) and makes everything a nice
registry.
This is the basis of a future system which might allow for more enemy
types to be used in the editor, and even custom enemy types...
But it was mostly done for cleanup, since I hated how the code looked.
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.
This fixes a bug where fast-forward wouldn't work in 30-FPS-only mode.
This is because the 30-FPS-only code has a hardcoded check for the
number 34, as in 34 milliseconds must pass before the next frame can
advance. This is why slowdown still worked, because slowdown means
you're waiting longer than 34 ms anyways, but fast-forward tries to wait
for only 1 ms, which wouldn't work if the 34 limit was still enforced.
So instead, swap out the 34 with game.get_timestep() and this will be
fixed.
Fixes#1185.
This fixes an issue where the CentOS CI kept failing because it couldn't
find the generated InterimVersion output file.
It seems like using the BYPRODUCTS statement in add_custom_target
didn't work because BYPRODUCTS was only added in CMake 3.2, so then
add_custom_target never ran, which is obviously a problem.
The solution is to use add_custom_command instead, and to solve the
problem that the interim version needs to be regenerated every time no
matter what (which is what BYPRODUCTS was supposed to do) we just add a
dummy output instead.
Previously, the interim version indicators (commit, date, and branch)
would go away on development builds if git didn't exist. And if it did
exist but provided blank output for whatever reason, that was almost
exactly the same as not having them at all (save for the window title
saying "VVVVVV []" which can be easy to overlook). This was bad because
it complicates troubleshooting when you potentially have an unofficial
or in-development build since those get distributed around or compiled
by some people frequently.
Now, there will always be an interim version indicators unless the game
is compiled with -DOFFICIAL_BUILD=ON. And if the indicators are blank
for any reason, they will just be replaced with placeholder defaults so
they will still show up.
GCC on CentOS will default to C90, it seems. This means it needs C99
explicitly specified for C-Hashmap and FAudio, or it will fail on them
using C99 features (variable declaration in a `for`-loop and the
`restrict` keyword, respectively).
