`twoframedelayfix()` now gets called in `resetplayer` due to #1258, to
fix the two-frame script delay when you respawn. Unfortunately, there
seems to be some strange bug where starting playtesting in a script box
activates the script twice. While I'm not exactly sure WHY this
happens logic-wise, we can quickly squash this issue by checking if
the player is reset due to dying.
* Load an unlimited amount of loose music
Binary blobs can now store 128 tracks, and music can now be read from
loose files. Unfortunately, the two cannot be used together -- loose
music can still only use 16 tracks. This commit attempts to fix that,
allowing for music playback by filename.
* Rework music track loading
The current "loose songs" system does not load files from custom
assets. This is from the #412 PR, and is NOT the "extra loose songs"
system that this PR implements, but they both work in the same area so
I decided to squash both of these bugs at once (plus, it helped clean
up the code and make a saner system, so...)
This commit also allows "loose music" to override music stored in the
`vvvvvvmusic.vvv` binary blob. When reading a blob, it will first check
if a loose file exists at the current path it's trying to find a track
at; if it exists, it will load that instead. If the blob does not
exist, the system will try to locate all expected built-in tracks
directly from the assets folder instead of doing that during blob
loading.
The `play` command has some safety removed due to an old exploit which
needs to be kept -- `music(5b)` should play track 5. This is used in
many levels and cannot be broken; unfortunately this means that we no
longer get the nice error when a song fails to be played, but that's
better than breaking a large amount of levels.
This commit does NOT address loading a "extra" loose track overtop of
a custom blob track, because with the current tooling, and the way it
will most likely continue to work in the future, every single custom
track in blobs have a completely empty path. If someone decides to
modify their blob in a hex editor or makes their own tooling, this
issue may show up again, but that is a problem which can and probably
should be addressed at a later date. The required code to solve such a
problem would be far more than what this PR should address, and for a
situation so unlikely, it's easy enough to just avoid adding the same
custom song twice, one in a music file, and one loose, because if
you're making a level, you're probably going to use one or the other.
* Fix mentioned issues from review
At some point, there was some "kludge" added to the game which allowed
script boxes to immediately get triggered when you enter a room, rather
than the update order unfortunately causing scripts to trigger after two
frames.
For some reason, dying and respawning in a room does not have the same
fix, causing really bad inconsistencies for anything that needs precise
timing.
Despite the initial implementation of the kludge being somewhat careless
and breaking levels which relied on timing, this one should not break
anything, but in fact fix things, surprisingly.
On certain ports of the game, and possibly some Linux distros, the
game's audio would crackle, or slow down with loud buzzing. This commit
attempts to fix that, by enabling `FAUDIO_1024_QUANTUM`, which should
increase the internal FAudio buffer size.
* Add undoing & redoing to the editor
It's very easy to make mistakes in VVVVVV's built-in level editor, with
no way to undo them. This commit adds an undo and redo system, bound to
CTRL+Z for undo and CTRL+Y for redo. The undo and redo stacks don't
have any limits, but could easily happen in the future. VVVVVV's data
is small enough where this should never be an issue, however.
No notes show up for undoing and redoing, because keeping track of what
specific action you're doing may bloat the system, and would get
annoying for the end-user. Notes are a bit annoying in general, even.
* Add level resizing to undo/redo system
* searchable gettext for undo/redo notes
* A few fixes and cleanup
The main fix was how holding right click to remove tiles did not
commit an action.
* Spikes also need to commit
* Cancelling placing a terminal/script box shouldn't have undo events
* Don't commit tile events if removing entities
* Clear redo buffer on level load
* Remove unneeded pointers from memcpy
* Add strings to lang files
* Fix definition in Editor.h
* Explain double-uncommit
* Don't unconditionally commit tiles on room change
I'm not that sure what I was thinking back then, but switching rooms
would commit tiles no matter what, causing a huge mess. The behavior
was intended to stop the "tile placement" action and commit it, but
just happened no matter what... So this has been fixed, and a few
comments have been added as well.
* Fix mentioned issues & make process_undo static
---------
Co-authored-by: NyakoFox <nyakowofox@gmail.com>
Past solutions were just "recache the screen textures under these known
circumstances" where whenever things OUTSIDE of those known
circumstances happened, the issue would reoccur.
I recently learned about an SDL event, `SDL_RENDER_TARGETS_RESET`,
which is for this exact problem. I ripped out all of the other places
`Screen::recacheTextures()` was called, and just slotted it in there,
and it worked perfectly.
...well, the old behavior worked perfectly; but the old behavior was
flawed as well, because it only checked for "ingame_titlemode" (if
you're in the main menu during gameplay) and forgot to check for the
map screen... plus, it didn't ever regenerate the minimap in custom
levels, which is another "persistant" render target.
Hopefully, this is the last time we'll ever have to think about this
one. I'm certainly sick of it.
This should 100% be backported into 2.4, as the bug occurs there as
well.
The editor has never clamped mouse bounds, and instead relied on SDL to
return clamped mouse coordinates. Unfortunately, in #1140, this detail
was missed, and the behavior changed, allowing the cursor to leave the
bounds of the screen.
This isn't much of a problem most of the time because anything that
uses position as array indeces has bounds checks. Unfortunately,
placing entities outside of a room's bounds leads to entities you can't
ever touch ever again without modifying the level externally. This is
the worst with checkpoints, as pressing Enter in a room will now take
you to the out-of-bounds checkpoint, causing you to immediately wrap to
another room.
This fix should be backported to 2.4, as the issue can lead to level
files which need manual editing to fix!
The `gamestate` command has an argument to set the gamestate, but the
statedelay was always set to 0, despite the statedelay being an
important part of the gamestate system. This commit adds an optional
argument to set the statedelay.
TinyXML2 seems to sometimes return NULL when an element has either no
text or whitespace, instead of returning an empty string. Why it does
this, I'm not sure, but I have recently learned from Dav999 that it
will crash the game. Great.
This fixes music playback on FAudio 26.01.
FAudio 26.01 added bounds checks to FAudioSourceVoice_SubmitSourceBuffer
in 033498ab08f5a1349ed5723a47aaa87163654be6.
The calculation of nBlockAlign is currently incorrect. nBlockAlign is
set to the block size in bits, not in bytes, causing this new bounds
check to trip.
Similarly, the wav_length for sound effects is in bytes.
This command adds `ifversion`, as both a simplified and internal
command.
The system works like so:
- `ifversion(2.6,script2)` -> If you're on 2.6.0 or greater
- `ifversion(2.6.0,script2)` -> Same as above
- `ifversion(2.6.3,script2)` -> You're using 2.6.3 or greater
- `ifversion(2.5,script2)` -> You're using 2.5 or greater
- `ifversion(2,script2)` -> You're using 2.0.0 or greater (yep...)
`ReleaseVersion.h` has a few new defines to make this possible, being
`MAJOR_VERSION`, `MINOR_VERSION` and `PATCH_VERSION`. With the help of
a few macros, `RELEASE_VERSION` is now constructed using those.
Ethan mentioned how case sensitivity could be a concern -- this commit
lowers the filename to create the sound ID, and also strips spaces.
Script arguments are always lowered, and the spaces get removed, so the
IDs are modified to match this behavior. If someone types in the
command `playef(horses REALLY COOL)`, the argument will get converted
to `horsesreallycool`. Likewise, the filename "horses REALLY COOL.wav"
will get converted to `horsesreallycool`. To the level creator, they
can just enter the same name twice and their sound will play.
This commit also adds a warning for the `playef` script command. While
most creators do not open the console, some warning somewhere is
better than nothing. I do think we should eventually have some sort
of system where it's easier to view level warnings, but for now this
should be sufficient.
This commit allows the usage of new "extra" sounds in levels for use in
custom level scripting. Including `squid.ogg` inside of your sounds
folder will now allow for the usage of the command `playef(squid)`.
Additionally, you can play built-in sounds by name this way too,
instead of having to memorize the id (`playef(rescue)`).
However, you CANNOT play extra sounds through using their numerical
IDs, since those can shift around depending on the filesystem (or if
someone adds a new sound). Playing an extra sound by ID will NOT play
the sound.
This is another attempt at #902, being loosely based off of that PR.
Co-authored-by: Fussmatte <doormattion@gmail.com>
Fixes#1242.
Turns out it was a really simple fix - the X positions were good, but
the Y positions were always at the top of the screen regardless of the
height of the textbox. Now they're vertically centered respective to
the speaker.
This fixes our problem with Valgrind reporting a jump based on an
uninitialized value; see https://github.com/Tehreer/SheenBidi/issues/19
Just to be sure nothing unexpected happens, I tested that this doesn't
cause any changes in behavior by outputting bidi-transformed versions
of all strings in strings.xml to a file for both our Arabic and Persian
localizations before and after the update, and confirming that the
files are the same.
This includes translations that were missing translations, with varying
extent between different languages, for the following things:
- "X mode is enabled" in-game warnings
- "Press {button} to freeze/unfreeze gameplay" for the level debugger
- Some credits strings for the post-2.4.0 extra Spanish options, the
PT_BR proofread, and Persian
- The recent gamepad menu changes (#1229)
Furthermore:
- "TAB" (used in the level debugger string) is now a separate string
instead of being hardcoded, because some languages needed it
translated
- Added missing arrows to Arabic/Persian font (needed for the gamepad
menu, and also a translator menu actually)
When writing the initial stretch mode code, the existence of HiDPI
displays completely slipped my mind -- or at least I didn't realize
that they'd be a problem.
We implement scaling modes ourselves, so transforming the mouse
coordinates to our 320x240 viewport is done manually. Unfortunately,
that code did not take into account HiDPI scaling whatsoever, meaning
that all of the math which assumes the window size and the renderer
size is wrong.
To fix this, we use `SDL_GetWindowSizeInPixels` and `SDL_GetWindow` to
find the scaling factor, and then apply that to the mouse coordinates
to get the mouse coordinates in the pixel-space instead, and then we do
all of our normal logic after.
Due to our usage of `SDL_GetWindowSizeInPixels`, this bumps the minimum
SDL version to 2.26.0.
Closes#1235.
A SDL_GameControllerButton below 0 is out of array bounds, so that
should trip the assert and return GLYPH_UNKNOWN just like when the
value is too high.
This makes the following improvements to the gamepad bindings menu:
- The menu now shows a hint that you can press a button while any of
the bind options are selected (or that you can navigate away from
those options)
- Instead of button presses immediately setting a binding, they now
ask for confirmation: press the same button a second time to confirm
- You can now remove a binding, the same way you add it (this has the
same type of confirmation)
- This menu used to be inconsistent with pretty much every other menu
in the game by showing a permanent title and description for the menu
itself ("Game Pad", "Change controller options.") rather than showing
a title and description for the currently selected option.
This inconsistency is now fixed.
The Persian localizers noticed an issue where the translation for
"Dimension VVVVVV, 12:34:56" would become "VVVVVV, 12:34:56 noisnemiD",
rather than "12:34:56 ,VVVVVV noisnemiD" as expected. This was fixed
for Persian but the same issue also affected Arabic, so I added a
RIGHT-TO-LEFT MARK (U+200F) to fix it there as well.
This adds "Persian" to all the languages, and brings the Persian files
up-to-date (mainly removing outdated strings and adding some late 2.4
stuff that we'll contact all translators for soon)
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.
NyakoFox