The current mobile version of VVVVVV has three movement types: swipe,
d-pad and sides. Swipe is the default, but my PRs have only implemented
d-pad. This commit adds swipe and adds it as the default.
Basically, when you save and quit, if you have a save, it attempts to
return to the `play` menu. Unfortunately for us, if you don't have a
save first, that menu never existed. You went directly from `mainmenu`
to the gameplay state. Since `play` never existed, the code didn't
have any menu to return to, so no buttons got created.
My fix is simple: if the menu isn't found, just make it.
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.
