1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-10-31 16:29:41 +01:00
Commit graph

116 commits

Author SHA1 Message Date
Misa
b8a4b4dfe7 Restore previous oldxp/oldyp variables in favor of lerpoldxp/lerpoldyp
I was investigating a desync in my Nova TAS, and it turns out that
the gravity line collision functions check for the `oldxp` and `oldyp`
of the player, i.e. their position on the previous frame, along with
their position on the current frame. So, if the player either collided
with the gravity line last frame or this frame, then the player collided
with the gravity line this frame.

Except, that's not actually true. It turns out that `oldxp` and `oldyp`
don't necessarily always correspond to the `xp` and `yp` of the player
on the previous frame. It turns out that your `oldyp` will be updated if
you stand on a vertically moving platform, before the gravity line
collision function gets ran. So, if you were colliding with a gravity
line on the previous frame, but you got moved out of there by a
vertically moving platform, then you just don't collide with the gravity
line at all.

However, this behavior changed in 2.3 after my over-30-FPS patch got
merged (#220). That patch took advantage of the existing `oldxp` and
`oldyp` entity attributes, and uses them to interpolate their positions
during rendering to make everything look real smooth.

Previously, `oldxp` and `oldyp` would both be updated in
`entityclass::updateentitylogic()`. However, I moved it in that patch to
update right before `gameinput()` in `main.cpp`.

As a result, `oldyp` no longer gets updated whenever the player stands
on a vertically moving platform. This ends up desyncing my TAS.

As expected, updating `oldyp` in `entityclass::movingplatformfix()` (the
function responsible for moving the player whenever they stand on a
vertically moving platform) makes it so that my TAS syncs, but the
visuals are glitchy when standing on a vertically moving platform. And
as much as I'd like to get rid of gravity lines checking for whether
you've collided with them on the previous frame, doing that desyncs my
TAS, too.

In the end, it seems like I should just leave `oldxp` and `oldyp` alone,
and switch to using dedicated variables that are never used in the
physics of the game. So I'm introducing `lerpoldxp` and `lerpoldyp`, and
replacing all instances of using `oldxp` and `oldyp` that my over-30-FPS
patch added, with `lerpoldxp` and `lerpoldyp` instead.

After doing this, and applying #503 as well, my Nova TAS syncs after
some minor but acceptable fixes with Viridian's walkingframe.
2020-10-11 16:19:26 -04:00
Misa
71c8c54313 Clean up music handling to one place
Previously, setting the actual volume of the music was all over the
place. Which isn't bad, but when I added being able to press N to mute
the music specifically, I should've made it so that there would be a
volume variable somewhere that the game looks at if the music is
unmuted, and otherwise sets the actual volume to 0 if the game is muted.

This resulted in things like #400 and #505 and having to add a bunch of
special-cased checks like game.musicmuted and game.completestop. But
instead of adding a bunch of special-case code, just make it so there's
a central place where Mix_VolumeMusic() actually gets called, and if
some piece of code wants to set the music volume, they can set
music.musicVolume. But the music handling logic in main.cpp gets the
final say on whether to listen to music.musicVolume, or to mute the game
entirely.

This is how the music handling code should have been from the start
(when pressing N to mute the music was added).

Fixes #505.
2020-10-11 16:16:57 -04:00
Misa
d7040b23d0 Axe manual state trackers and use SDL_IsTextInputActive()
After looking at pull request #446, I got a bit annoyed that we have TWO
variables, key.textentrymode and ed.textentry, that we rolled ourselves
to track the state of something SDL already provides us a function to
easily query: SDL_IsTextInputActive(). We don't need to have either of
these two variables, and we shouldn't.

So that's what I do in this patch. Both variables have been axed in
favor of using this function, and I just made a wrapper out of it, named
key.textentry().

For bonus points, this gets rid of the ugly NO_CUSTOM_LEVELS and
NO_EDITOR ifdef in main.cpp, since text entry is enabled when entering
the script list and disabled when exiting it. This makes the code there
easier to read, too.

Furthermore, apparently key.textentrymode was initialized to *true*
instead of false... for whatever reason. But that's gone now, too.

Now, you'd think there wouldn't be any downside to using
SDL_IsTextInputActive(). After all, it's a function that SDL itself
provides, right?

Wrong. For whatever reason, it seems like text input is active *from the
start of the program*, meaning that what would happen is I would go into
the editor, and find that I can't move around nor place tiles nor
anything else. Then I would press Esc, and then suddenly become able to
do those things I wanted to do before.

I have no idea why the above happens, but all I can do is to just insert
an SDL_StopTextInput() immediately after the SDL_Init() in main.cpp. Of
course, I have to surround it with an SDL_IsTextInputActive() check to
make sure I don't do anything extraneous by stopping input when it's
already stopped.
2020-08-13 17:51:38 -04:00
Nichole Mattera
d865c37951 Fixed the title screen showing up when going to graphics options while playtesting. 2020-08-13 10:03:48 -04:00
Nichole Mattera
ab323a7550 Simplified the fixes. 2020-08-12 23:07:13 -04:00
Misa
78e87effe7 Replace all usages of atoi() with help.Int()
This will prevent any undefined behavior that might occur as a result of
having invalid input passed into atoi().
2020-08-07 01:00:49 -04:00
Misa
57dca99a4e Ax OverlaySurfaceKeyed(), set proper foregroundBuffer blend mode
So, earlier in the development of 2.0, Simon Roth (I presume)
encountered a problem: Oh no, all my backgrounds aren't appearing! And
this is because my foregroundBuffer, which contains all the drawn tiles,
is drawing complete black over it!

So he had a solution that seems ingenius, but is actually really really
hacky and super 100% NOT the proper solution. Just, take the
foregroundBuffer, iterate over each pixel, and DON'T draw any pixel
that's 0xDEADBEEF. 0xDEADBEEF is a special signal meaning "don't draw
this pixel". It is called a 'key'.

Unfortunately, this causes a bug where translucent pixels on tiles
(pixels between 0% and 100% opacity) didn't get drawn correctly. They
would be drawn against this weird blue color.

Now, in #103, I came across this weird constant and decided "hey, this
looks awfully like that weird blue color I came across, maybe if I set
it to 0x00000000, i.e. complete and transparent black, the issue will be
fixed". And it DID appear to be fixed. However, I didn't look too
closely, nor did I test it that much, and all that ended up doing was
drawing the pixels against black, which more subtly disguised the
problem with translucent pixels.

So, after some investigation, I noticed that BlitSurfaceColoured() was
drawing translucent pixels just fine. And I thought at the time that
there was something wrong with BlitSurfaceStandard(), or something.
Further along later I realized that all drawn tiles were passing through
this weird OverlaySurfaceKeyed() function. And removing it in favor of a
straight SDL_BlitSurface() produced the bug I mentioned above: Oh no,
all the backgrounds don't show up, because my foregroundBuffer is
drawing pure black over them!

Well... just... set the proper blend mode for foregroundBuffer. It
should be SDL_BLENDMODE_BLEND instead of SDL_BLENDMODE_NONE.

Then you don't have to worry about your transparency at all. If you did
it right, you won't have to resort this hacky color-keying business.

*sigh*
2020-08-06 22:10:30 -04:00
Misa
1a64e9c528 Remove unnecessary cursor toggling when toggling fullscreen
For some reason, the cursor would be either disabled and re-enabled if
you switched to windowed mode, or it would be always enabled if you
switched to fullscreen mode. This only happened when you toggled
fullscreen using the Alt+Enter, Alt+F, or F11 keybinds, and the
fullscreen option in graphic options doesn't have this problem.

This cursor toggling business seems like an arcane incantation back in
the days of SDL1.2, now since no longer necessary with SDL2. However,
after some testing, it seems like removing these indecipherable runes
don't cause any harm, so I'm going to remove them.

Fixes #371.
2020-08-06 22:08:20 -04:00
Misa
30123e700d Print error and return if given invalid command-line arg
This is helpful to know if the user either spelled an arg wrong, or
spelled it right but nothing is happening.
2020-08-03 00:39:58 -04:00
AllyTally
06e5eb38d9 Fix #380
Achievements could be unlocked in custom levels/make and play, so this adds the wrapper function `game.unlockAchievement` which calls `NETWORK_unlockAchievement` if `map.custommode` is false.
Also, this function and `Game::unlocknum` have both been `ifdef`ed to be empty if MAKEANDPLAY is defined.
2020-08-01 16:09:24 -04:00
Misa
52f7a587fe Separate includes into sections and alphabetize them
Okay, so basically here's the include layout that this game now
consistently uses:

[The "main" header file, if any (e.g. Graphics.h for Graphics.cpp)]
[blank line]
[All system includes, such as tinyxml2/physfs/utfcpp/SDL]
[blank line]
[All project includes, such as Game.h/Entity.h/etc.]

And if applicable, another blank line, and then some special-case
include screwy stuff (take a look at editor.cpp or FileSystemUtils.cpp,
for example, they have ifdefs and defines with their includes).
2020-07-19 21:37:40 -04:00
Misa
b5ff65c84e Remove unnecessary includes from header files
Including a header file inside another header file means a bunch of
files are going to be unnecessarily recompiled whenever that inner
header file is changed. So I minimized the amount of header files
included in a header file, and only included the ones that were
necessary (system includes don't count, I'm only talking about includes
from within this project). Then the includes are only in the .cpp files
themselves.

This also minimizes problems such as a NO_CUSTOM_LEVELS build failing
because some file depended on an include that got included in editor.h,
which is another benefit of removing unnecessary includes from header
files.
2020-07-19 21:37:40 -04:00
Misa
ecf43d05dc Fix undeffing ARG_IS instead of ARG
Whoops.

Noticed this earlier when I was merging upstream back into VCE, and
interestingly enough, it doesn't look like cppcheck warns about
undeffing a non-existent define.
2020-07-15 22:57:50 -04:00
Misa
5e94239967 Optimize 30-mode FPS loop to use SDL_Delay()
This patch optimizes the loop used to limit the framerate in 30-FPS-only
mode so that it uses SDL_Delay() instead of an accumulator. This means
that the game will take up less CPU power in 30-FPS-only mode. This also
means that the game loop code has been simplified, so there's only two
while-loops, and only two places where game.over30mode is checked, thus
leading to easier-to-understand logic.

Using an accumulator here would essentially mean busywaiting until the
34 millisecond timer was up. (The following is just what leo60228 told
me.) Busywaiting is bad because it's inefficient. The operating system
assumes that if you're busywaiting, you're performing a complex
calculation and handles your process accordingly. And this is why
sleeping was invented, so you could busywait without taking up
unnecessary CPU time.
2020-07-14 00:44:42 -04:00
Misa
199a8f45d6 Fix -playmusic command line option not working
There's a bug where playtesting from Ved doesn't properly play the music
of the level, due to no fault with Ved.

This was because the music was being faded out by
scriptclass::startgamemode() case 23 after main() called music.play().
To fix this, just call music.play() when all the other variables are
being set in Game::customloadquick().
2020-07-11 15:03:37 -04:00
Ethan Lee
d3f9a36941 Refactor startup to load config before calling Screen::init 2020-07-08 14:30:57 -04:00
Ethan Lee
0f450f3e39 Move the VSync work to Screen.
The problem we're running into is entirely contained in the Screen - we need to
either decouple graphics context init from Screen::init or we need to take out
the screenbuffer interaction from loadstats (which I'm more in favor of since we
can just pull the config values and pass them to Screen::init later).
2020-07-02 00:19:40 -04:00
Misa
2569154010 Don't adhere to slowdown in MAPMODE/TELEPORTERMODE
Now that you have a mini menu in MAPMODE, it's a bit annoying to have to
deal with the slowed-down timestep when pressing left/right/ACTION
inside it. Especially since going to an options menu restores the
timestep back to normal (because it's in TITLEMODE). Also removed it
from TELEPORTERMODE for consistency.
2020-07-01 11:39:17 -04:00
Misa
e331abcd7e Fix Alt+Enter Glitch if not in glitchrunner mode
The Alt+Enter Glitch is a funny glitch where if you press any toggle
fullscreen keybind during a cutscene, Viridian will stop moving (if
they're being moved by a walk()) and ACTION will start being held down
for them. Meaning in most cases you can interrupt a walk and flip at the
same time.

This can obviously break cutscenes if a casual just wants to toggle
fullscreen, so I'm fixing it. But it will be unfixed in glitchrunner
mode in case you want to glitch out custom levels (I know I do).

More information on the Alt+Enter Glitch is available here:
https://gitgud.io/infoteddy/vvvvvv-knowledge/blob/master/bugs/bugs.md#the-altenter-glitch
(The page is a bit outdated, some bugs have been fixed in 2.3 already.)
2020-06-30 00:20:03 -04:00
Misa
ebd381c228 Fix the two-frame-delay when entering a room with an "init" script
This patch is very kludge-y, but at least it fixes a semi-noticeable
visual issue in custom levels that use internal scripts to spawn
entities when loading a room.

Basically, the problem here is that when the game checks for script
boxes and sets newscript, newscript has already been processed for that
frame, and when the game does load a script, script.run() has already
been processed for that frame.

That issue can be fixed, but it turns out that due to my over-30-FPS
game loop changes, there's now ANOTHER visible frame of delay between
room load and entity creation, because the render function gets called
in between the script being loaded at the end of gamelogic() and the
script actually getting run.

So... I have to temporary move script.run() to the end of gamelogic()
(in map.twoframedelayfix()), and make sure it doesn't get run next
frame, because double-evaluations are bad. To do that, I have to
introduce the kludge variable script.dontrunnextframe, which does
exactly as it says.

And with all that work, the two-frame (now three-frame) delay is fixed.
2020-06-29 15:42:51 -04:00
Misa
a87ebd2945 Remove unnecessary middleman game.infocus
It does the same thing as key.isActive, so no need to make it a separate
variable.
2020-06-27 17:23:07 -04:00
Misa
6648246662 Fix -playx/y/rx/ry/gc/music looking at wrong argument
In my previous PR, I wrongly assumed that I could just replace the `i`
handling code of those options with an `i++;` at the beginning, and thus
I could put all blocks' `i++;` into ARG_INNER(). Well I was wrong,
because the code was written the original way for a reason, namely that
we still need `i` to point to the -playx/y/rx/ry/gc/music argv so we can
re-compare which argument led us into this code block.
2020-06-21 21:44:02 -04:00
Misa
afd16ebc73 Add puts() if FILESYSTEM_init() fails
Just to be helpful if someone has a failing FILESYSTEM_init(), but
doesn't know that's their issue and keeps wondering why VVVVVV just
exits with code 1.
2020-06-21 20:25:22 -04:00
Misa
9001a68833 De-duplicate and add safety checks to CLI args, fix brace style
The command-line argument parsing code has a lot of copy-paste. This
copy-paste would get even worse if I added safety checks to make sure
you couldn't index argv out-of-bounds by having an argument like
`-renderer` without having anything after it, i.e. you'd be doing the
command `./VVVVVV -renderer`.

Previously, only the playtest arguments (apart from the recently-added
`playassets`) had this safety check, but the message it printed whenever
the safety check failed was always "-playing option requires one
argument" regardless of whatever argument actually failed to be parsed.
So I fixed it so that all arguments actually output the correct
corresponding failed argument instead.

Also, `strcmp(argv[i], <name>) == 0` is really kind of noisy, even if
you understand what it does perfectly well.

So I refactored it with a bunch of macros. ARG() just does the strcmp()
char* comparison, and ARG_INNER() does the safety check and returns 1,
along with printing a message, if the safety check fails.
2020-06-21 20:25:22 -04:00
Misa
93b13cadac Add -playassets command-line option
This is used if you're loading a level file from STDIN. The game needs
to know the actual level assets directory you're referring to, since
when it gets the level from STDIN, it doesn't know the actual filename
of the level.

Fixes #309.
2020-06-21 20:25:22 -04:00
Misa
c6e800db6f Add '#if !defined(NO_EDITOR)' guards around editorinput/render/logic
These functions aren't needed in a NO_EDITOR build, so it's useful to
reduce the binary size this way.
2020-06-19 18:35:03 -04:00
Misa
5c7e869ee7 Work around SDL2 bug where VSync hint only applies on renderer creation
Ugh, this is terrible and stupid and I hate myself for it.

Anyway, since the SDL2 VSync hint only applies when the renderer is
created, we have to re-create the renderer whenever VSync is toggled.
However, this also means we need to re-create m_screenTexture as well,
AND call ResizeScreen() after that or else the letterbox/integer modes
won't be applied.

Unfortunately, this means that in main(), gameScreen.init() will create
a renderer only to be destroyed later by graphics.processVsync().
There's not much we can do about this. Fixing this would require putting
graphics.processVsync() before gameScreen.init(). However, in order to
know whether the user has VSync set, we would have to call
game.loadstats() first, but wait, we can't, because game.loadstats()
mutates gameScreen! Gahhhhhh!!!!

@leo60228 suggested to fix that problem (
https://github.com/TerryCavanagh/VVVVVV/pull/220#issuecomment-624217939
) by adding NULL checks to game.loadstats() and then calling it twice,
but then you're trading wastefully creating a renderer only to be
destroyed, for wastefully opening and parsing unlock.vvv twice instead
of once. In either case, you're doing something twice and wasting work.
2020-06-19 17:44:53 -04:00
Misa
0cb21f407e Add inline directives to gameloop(), deltaloop(), fixedloop()
This is to make sure that there's no cost splitting up the game loop
into several different functions to increase code readability.
2020-06-19 09:05:48 -04:00
Misa
7640f8cc8f Add NO_CUSTOM_LEVELS guard around EDITORMODE in deltaloop()
Otherwise a NO_CUSTOM_LEVELS build would fail. Also I got rid of the
'graphics.flipmode = false;' in the fixed loop because I don't think it
does anything.
2020-06-19 09:05:48 -04:00
Misa
867e7bc1e6 Move infocus and network updates to fixedloop()
Updating them every delta frame is way too fast.
2020-06-19 09:05:48 -04:00
Misa
acf47bfeac Unindent fixedloop()
If I did it in the previous commit, it would've been too noisy.
2020-06-19 09:05:48 -04:00
Misa
a9f07ccc8f Move fixed loop to its own function
To improve code readability because otherwise the code would be one
giant blob.
2020-06-19 09:05:48 -04:00
Misa
1fbec9c427 Unindent deltaloop()
Doing it in the same commit makes the diffs too noisy...
2020-06-19 09:05:48 -04:00
Misa
c9aea52385 Move delta loop to its own function
Makes the code less of a giant blob, again.
2020-06-19 09:05:48 -04:00
Misa
e294b92785 Unindent gameloop()
You know the drill, diffs are too impatient to properly illustrate an
indentation change without adding a bunch of noise.
2020-06-19 09:05:48 -04:00
Misa
a8d2994223 Put the main game loop inside its own function
Makes main() less of one giant blob of code.
2020-06-19 09:05:48 -04:00
Misa
3d674a6550 Rename time to time_
This is needed for the next step. I want to put all the loop stuff in
their own functions so the code isn't one huge blob, but to do that I'll
need to make 'time' a global variable, but I can't do that because
actually 'time' is already a function, apparently, and you're only
allowed to shadow variables when already inside a function.
2020-06-19 09:05:48 -04:00
Misa
18ecc00d6d Set alpha to 1 in 30-FPS-only mode
This is to make sure no lerping occurs in 30-FPS mode, otherwise things
might look weird. A good case that this fixes is how entities look in a
double-gotoroom (they should be completely frozen in 30-FPS mode).
2020-06-19 09:05:48 -04:00
Misa
694e8f42ab Add VSync graphics option, off by default
This is if you want delta-timesteps to go as quickly as possible. Also
it seems like on Windows this only has an effect in exclusive fullscreen
mode.
2020-06-19 09:05:48 -04:00
Misa
179315c889 Indent game loop yet again
This is because in the previous commit I put braces around it because I
needed to have a delta-timestep limiter.
2020-06-19 09:05:48 -04:00
Misa
7f526f3ef2 Add being able to toggle over/fixed-30-FPS, off by default
There is now an option in "graphic options" named "toggle fps", which
toggles whether the game visually runs at 1000/34 FPS or over 1000/34
FPS. It is off by default.

I've had to put the entire game loop in yet another set of braces, I'll
indent it next commit.
2020-06-19 09:05:48 -04:00
Misa
b5b958561c Move preloader update code to new function preloaderlogic()
Otherwise the preloader will go by way too quickly.
2020-06-19 09:05:48 -04:00
Misa
97b8e062ff Move analogue mode filter update logic to fixed-timestep loop
Otherwise if the analogue filter is scrolling, it'll scroll by REALLY
fast.
2020-06-19 09:05:48 -04:00
Misa
2333087c27 Remove duplicate -renderer option
Guess this was here from when Leo added command-line playtesting.
2020-06-19 09:05:48 -04:00
Misa
4be18ff9fe Add v-sync hint
This is because otherwise, on my Linux system at least, the game will
take up a lot of CPU that it doesn't really need to (I only have a 60hz
monitor).

On Windows, it looks like Windows already enforces V-sync for
applications anyway, unless they have exclusive fullscreen control.
Linux doesn't enforce V-sync on apps and lets them take up as much CPU
as they want, so I'm putting this here to limit the framerate.

The game is already actually 30 FPS anyway, the nice smooth FPS is just
visual. V-sync won't introduce any more "input lag" than already exists.
2020-06-19 09:05:48 -04:00
Misa
c009ab67d9 Make slowdown only apply in GAMEMODE/MAPMODE/TELEPORTERMODE
As much as it looks cool to have a slowly-scrolling background on the
title screen, it's quite annoying that slowmode applying on the title
screen mean that your keypresses are less responsive.
2020-06-19 09:05:48 -04:00
Misa
1e81aef58a Fix flickering on bottom/right of screen with H/V warp BGs
To fix this, I draw another row/column of incoming textures. But of
course, I have to extend the size of the towerbuffer, otherwise the
incoming textures will just be gone.
2020-06-19 09:05:48 -04:00
Misa
c7d3a684ea Interpolate horizontal warp BG
So that it's really, really smooth. Only noticeable in slowdown mode,
though.
2020-06-19 09:05:48 -04:00
Misa
40cedc8c94 Move general oldxp/oldyp updating to just before gameinput()
This has to be done in order to fix rendering when on a conveyor or
moving platform and actively moving with or against it. Pretty sure this
shouldn't break anything, oldxp/oldyp is mostly visual after all (and by
the time it's used for gravity line collision checking,
updateentitylogic() would've already gotten around to it anyway).

Incidentally, this also fixes a jitter that would occur if you were
moving at the time you died or collected a trinket or custom crewmate,
due to the game temporarily freezing and either doing deathsequence or
completestop.
2020-06-19 09:05:48 -04:00
Misa
8fde6f28a3 Update screenshake position in fixed-timestep loop
Otherwise the screen will shake too fast for my liking.

Also I'm planning to add an FPS limiting option later (because right
now, un-capping the FPS is pretty wasteful and eats up lots of
resources, especially since I have only a 60hz monitor), and it'd feel
weird if screen shaking updated every delta timestep.
2020-06-19 09:05:48 -04:00