2020-09-28 04:15:06 +02:00
|
|
|
#define KEY_DEFINITION
|
2020-01-01 21:29:24 +01:00
|
|
|
#include "KeyPoll.h"
|
2020-07-19 21:43:29 +02:00
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
#include <string.h>
|
2020-01-31 19:25:37 +01:00
|
|
|
#include <utf8/unchecked.h>
|
2020-01-01 21:29:24 +01:00
|
|
|
|
Call VVV_exit() when SDL_QUIT is received
This fixes a regression introduced by #535 where a quit signal (e.g.
Ctrl-C) sent to the window while the game was in unfocus pause wouldn't
close the game.
One problem was that key.quitProgram would only be checked when control
flow switched back to the outer loop in main(), which would only happen
when the loop order state machine switched to a delta function. As the
unfocused func table didn't have any delta functions, this means
key.quitProgram would never be checked.
So a naïve solution to this would just be to add a no-op delta func
entry to the unfocused func table. However, we then run into a separate
issue where a delta function at the end of a func list never reassigns
the active funcs, causing the game to be stuck in the unfocus pause
forever. Active func reassignment only happens after fixed funcs. So
then a naïve solution after that would be to simply add a no-op fixed
func entry after that. And indeed, that would fix the whole issue.
However, I want to do things the right way. And this does not seem like
the right way. Even putting aside the separate last-func-being-delta
issue, it mandates that every func list needs a delta function. Which
seems quite unnecessary to me.
Another solution I considered was copy-pasting the key.quitProgram check
to the inner loops, or adding some sort of signal propagation to
the inner loops - implemented by copy-pasting checks after each loop -
so we didn't need to copy-paste key.quitProgram... but that seems really
messy, too.
So, I realized that we could throw away key.quitProgram, and simply call
VVV_exit() directly when we receive an SDL_QUIT event. This fixes the
issue, this removes an unnecessary middleman variable, and it's pretty
cleanly and simply the right thing to do.
2021-04-02 00:24:14 +02:00
|
|
|
#include "Exit.h"
|
2020-07-19 21:43:29 +02:00
|
|
|
#include "Game.h"
|
Split glitchrunner mode into multiple versions
Previously, turning glitchrunner mode on essentially locked you to
emulating 2.0, and turning it off just meant normal 2.3 behavior. But
what if you wanted 2.2 behavior instead? Well, that's what I had to ask
when a TAS of mine would desync in 2.3 because of the two-frame delay
fix (glitchrunner off), but would also desync because of 2.0 warp lines
(glitchrunner on).
What I've done is made it so there are three states to glitchrunner mode
now: 2.0 (previously just the "on" state), 2.2 (previously a state you
couldn't use), and "off". Furthermore, I made it an enum, so in case
future versions of the game patch out more glitches, we can add them to
the enum (and the only other thing we have to update is a lookup table
in GlitchrunnerMode.c). Also, 2.2 glitches exist in 2.0, so you'll want
to use GlitchrunnerMode_less_than_or_equal() to check glitchrunner
version.
2021-08-05 02:09:49 +02:00
|
|
|
#include "GlitchrunnerMode.h"
|
2020-07-19 21:43:29 +02:00
|
|
|
#include "Graphics.h"
|
|
|
|
|
#include "Music.h"
|
2021-02-24 00:21:29 +01:00
|
|
|
#include "Vlogging.h"
|
2020-07-19 21:43:29 +02:00
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
int inline KeyPoll::getThreshold(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-11-13 02:16:18 +01:00
|
|
|
switch (sensitivity)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-11-13 02:16:18 +01:00
|
|
|
case 0:
|
|
|
|
|
return 28000;
|
|
|
|
|
case 1:
|
|
|
|
|
return 16000;
|
|
|
|
|
case 2:
|
|
|
|
|
return 8000;
|
|
|
|
|
case 3:
|
|
|
|
|
return 4000;
|
|
|
|
|
case 4:
|
|
|
|
|
return 2000;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
2020-11-13 02:16:18 +01:00
|
|
|
return 8000;
|
|
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
KeyPoll::KeyPoll(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
|
xVel = 0;
|
|
|
|
|
yVel = 0;
|
2020-11-13 02:16:18 +01:00
|
|
|
// 0..5
|
|
|
|
|
sensitivity = 2;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
keybuffer="";
|
|
|
|
|
leftbutton=0; rightbutton=0; middlebutton=0;
|
|
|
|
|
mx=0; my=0;
|
|
|
|
|
resetWindow = 0;
|
|
|
|
|
pressedbackspace=false;
|
|
|
|
|
|
Fix frame-ordering backspacing empty line bug in script editor
There is a long-standing bug with the script editor where if you delete
the last character of a line, it IMMEDIATELY deletes the line you're on,
and then moves your cursor back to the previous line. This is annoying,
to say the least.
The reason for this is that, in the sequence of events that happens in
one frame (known as frame ordering), the code that backspaces one
character from the line when you press Backspace is ran BEFORE the code
to remove an empty line if you backspace it is ran. The former is
located in key.Poll(), and the latter is located in editorinput().
Thus, when you press Backspace, the game first runs key.Poll(), sees
that you've pressed Backspace, and dutifully removes the last character
from a line. The line is now empty. Then, when the game gets around to
the "Are you pressing Backspace on an empty line?" check in
editorinput(), it thinks that you're pressing Backspace on an empty
line, and then does the usual line-removing stuff.
And actually, when it does the check in editorinput(), it ACTUALLY asks
"Are you pressing Backspace on THIS frame and was the line empty LAST
frame?" because it's checking against its own copy of the input buffer,
before copying the input buffer to its own local copy. So the problem
only happens if you press and hold Backspace for more than 1 frame.
It's a small consolation prize for this annoyance, getting to
tap-tap-tap Backspace in the hopes that you only press it for 1 frame,
while in the middle of something more important to do like, oh I don't
know, writing a script.
So there are two potential solutions here:
(1) Just change the frame ordering around.
This is risky to say the least, because I'm not sure what behavior
depends on exactly which frame order. It's not like it's key.Poll()
and then IMMEDIATELY afterwards editorinput() is run, it's more
like key.Poll(), some things that obviously depend on key.Poll()
running before them, and THEN editorinput(). Also, editorinput() is
only one possible thing that could be ran afterwards, on the next
frame we could be running something else entirely instead.
(2) Add a kludge variable to signal when the line is ALREADY empty so
the game doesn't re-check the already-empty line and conclude that
you're already immediately backspacing an empty line.
I went with (2) for this commit, and I've added the kludge variable
key.linealreadyemptykludge.
However, that by itself isn't enough to fix it. It only adds about a
frame or so of delay before the game goes right back to saying "Oh,
you're ALREADY somehow pressing backspace again? I'll just delete this
line real quick" and the behavior is basically the same as before,
except now you have to hit Backspace for TWO frames or less instead of
one in order to not have it happen.
What we need is to have a delay set as well, when the game deletes the
last line of a char. So I set ed.keydelay to 6 as well if editorinput()
sses that key.linealreadyemptykludge is on.
2020-01-19 03:17:46 +01:00
|
|
|
linealreadyemptykludge = false;
|
Fix resumemusic/musicfadein not working
It seems like they were unfinished. This commit makes them properly
work.
When a track is stopped with stopmusic() or musicfadeout(),
resumemusic() will resume from where the track stopped. musicfadein()
does the same but does it with a gradual fade instead of suddenly
playing it at full volume.
I changed several interfaces around for this. First, setting currentsong
to -1 when music is stopped is handled in the hook callback that gets
called by SDL_mixer whenever the music stops. Otherwise, it'd be
problematic if currentsong was set to -1 when the song starts fading out
instead of when the song actually ends.
Also, music.play() has a few optional arguments now, to reduce the
copying-and-pasting of music code.
Lastly, we have to roll our own tracker of music length by using
SDL_GetPerformanceCounter(), because there's no way to get the music
position if a song fades out. (We could implicitly keep the music
position if we abruptly stopped the song using Mix_PauseMusic(), and
resume it using Mix_ResumeMusic(), but ignoring the fact that those two
functions are also used on the unfocus-pause (which, as it turns out, is
basically a non-issue because the unfocus-pause can use some other
functions), there's no equivalent for fading out, i.e. there's no
"fade out and pause when it fully fades out" function in SDL_mixer.) And
then we have to account for the unfocus-pause in our manual tracker.
Other than that, these commands are now fully functional.
2020-06-27 10:31:09 +02:00
|
|
|
|
2020-07-06 22:04:34 +02:00
|
|
|
isActive = true;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void KeyPoll::enabletextentry(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
|
keybuffer="";
|
|
|
|
|
SDL_StartTextInput();
|
|
|
|
|
}
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void KeyPoll::disabletextentry(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
|
SDL_StopTextInput();
|
|
|
|
|
}
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
bool KeyPoll::textentry(void)
|
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 08:43:25 +02:00
|
|
|
{
|
|
|
|
|
return SDL_IsTextInputActive() == SDL_TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-17 07:26:34 +01:00
|
|
|
void KeyPoll::toggleFullscreen(void)
|
|
|
|
|
{
|
|
|
|
|
if (graphics.screenbuffer != NULL)
|
|
|
|
|
{
|
|
|
|
|
graphics.screenbuffer->toggleFullScreen();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
keymap.clear(); /* we lost the input due to a new window. */
|
Split glitchrunner mode into multiple versions
Previously, turning glitchrunner mode on essentially locked you to
emulating 2.0, and turning it off just meant normal 2.3 behavior. But
what if you wanted 2.2 behavior instead? Well, that's what I had to ask
when a TAS of mine would desync in 2.3 because of the two-frame delay
fix (glitchrunner off), but would also desync because of 2.0 warp lines
(glitchrunner on).
What I've done is made it so there are three states to glitchrunner mode
now: 2.0 (previously just the "on" state), 2.2 (previously a state you
couldn't use), and "off". Furthermore, I made it an enum, so in case
future versions of the game patch out more glitches, we can add them to
the enum (and the only other thing we have to update is a lookup table
in GlitchrunnerMode.c). Also, 2.2 glitches exist in 2.0, so you'll want
to use GlitchrunnerMode_less_than_or_equal() to check glitchrunner
version.
2021-08-05 02:09:49 +02:00
|
|
|
if (GlitchrunnerMode_less_than_or_equal(Glitchrunner2_2))
|
2021-03-17 07:26:34 +01:00
|
|
|
{
|
|
|
|
|
game.press_left = false;
|
|
|
|
|
game.press_right = false;
|
|
|
|
|
game.press_action = true;
|
|
|
|
|
game.press_map = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-17 07:46:43 +02:00
|
|
|
static int changemousestate(
|
|
|
|
|
int timeout,
|
|
|
|
|
const bool show,
|
|
|
|
|
const bool hide
|
|
|
|
|
) {
|
|
|
|
|
int prev;
|
|
|
|
|
int new_;
|
|
|
|
|
|
|
|
|
|
if (timeout > 0)
|
|
|
|
|
{
|
|
|
|
|
return --timeout;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If we want to both show and hide at the same time, prioritize showing */
|
|
|
|
|
if (show)
|
|
|
|
|
{
|
|
|
|
|
new_ = SDL_ENABLE;
|
|
|
|
|
}
|
|
|
|
|
else if (hide)
|
|
|
|
|
{
|
|
|
|
|
new_ = SDL_DISABLE;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
return timeout;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
prev = SDL_ShowCursor(SDL_QUERY);
|
|
|
|
|
|
|
|
|
|
if (prev == new_)
|
|
|
|
|
{
|
|
|
|
|
return timeout;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SDL_ShowCursor(new_);
|
|
|
|
|
|
|
|
|
|
switch (new_)
|
|
|
|
|
{
|
|
|
|
|
case SDL_DISABLE:
|
|
|
|
|
timeout = 0;
|
|
|
|
|
break;
|
|
|
|
|
case SDL_ENABLE:
|
|
|
|
|
timeout = 30;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return timeout;
|
|
|
|
|
}
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
void KeyPoll::Poll(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-04-17 07:46:43 +02:00
|
|
|
static int mousetoggletimeout = 0;
|
|
|
|
|
bool showmouse = false;
|
|
|
|
|
bool hidemouse = false;
|
2020-08-13 03:08:25 +02:00
|
|
|
bool altpressed = false;
|
2021-03-17 07:26:34 +01:00
|
|
|
bool fullscreenkeybind = false;
|
2020-01-01 21:29:24 +01:00
|
|
|
SDL_Event evt;
|
|
|
|
|
while (SDL_PollEvent(&evt))
|
|
|
|
|
{
|
2020-06-27 03:17:01 +02:00
|
|
|
switch (evt.type)
|
|
|
|
|
{
|
2020-01-01 21:29:24 +01:00
|
|
|
/* Keyboard Input */
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_KEYDOWN:
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
|
keymap[evt.key.keysym.sym] = true;
|
2020-03-13 00:29:03 +01:00
|
|
|
|
2020-01-01 21:29:24 +01:00
|
|
|
if (evt.key.keysym.sym == SDLK_BACKSPACE)
|
|
|
|
|
{
|
|
|
|
|
pressedbackspace = true;
|
|
|
|
|
}
|
2020-03-13 00:29:03 +01:00
|
|
|
|
2020-03-13 00:00:18 +01:00
|
|
|
#ifdef __APPLE__ /* OSX prefers the command keys over the alt keys. -flibit */
|
2020-08-13 03:08:25 +02:00
|
|
|
altpressed = keymap[SDLK_LGUI] || keymap[SDLK_RGUI];
|
2020-01-01 21:29:24 +01:00
|
|
|
#else
|
2020-08-13 03:08:25 +02:00
|
|
|
altpressed = keymap[SDLK_LALT] || keymap[SDLK_RALT];
|
2020-01-01 21:29:24 +01:00
|
|
|
#endif
|
2020-03-13 00:29:03 +01:00
|
|
|
bool returnpressed = evt.key.keysym.sym == SDLK_RETURN;
|
|
|
|
|
bool fpressed = evt.key.keysym.sym == SDLK_f;
|
|
|
|
|
bool f11pressed = evt.key.keysym.sym == SDLK_F11;
|
|
|
|
|
if ((altpressed && (returnpressed || fpressed)) || f11pressed)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-03-17 07:26:34 +01:00
|
|
|
fullscreenkeybind = true;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
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 08:43:25 +02:00
|
|
|
if (textentry())
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-01-31 19:25:37 +01:00
|
|
|
if (evt.key.keysym.sym == SDLK_BACKSPACE && !keybuffer.empty())
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-01-31 19:25:37 +01:00
|
|
|
std::string::iterator iter = keybuffer.end();
|
|
|
|
|
utf8::unchecked::prior(iter);
|
|
|
|
|
keybuffer = keybuffer.substr(0, iter - keybuffer.begin());
|
|
|
|
|
if (keybuffer.empty())
|
Fix frame-ordering backspacing empty line bug in script editor
There is a long-standing bug with the script editor where if you delete
the last character of a line, it IMMEDIATELY deletes the line you're on,
and then moves your cursor back to the previous line. This is annoying,
to say the least.
The reason for this is that, in the sequence of events that happens in
one frame (known as frame ordering), the code that backspaces one
character from the line when you press Backspace is ran BEFORE the code
to remove an empty line if you backspace it is ran. The former is
located in key.Poll(), and the latter is located in editorinput().
Thus, when you press Backspace, the game first runs key.Poll(), sees
that you've pressed Backspace, and dutifully removes the last character
from a line. The line is now empty. Then, when the game gets around to
the "Are you pressing Backspace on an empty line?" check in
editorinput(), it thinks that you're pressing Backspace on an empty
line, and then does the usual line-removing stuff.
And actually, when it does the check in editorinput(), it ACTUALLY asks
"Are you pressing Backspace on THIS frame and was the line empty LAST
frame?" because it's checking against its own copy of the input buffer,
before copying the input buffer to its own local copy. So the problem
only happens if you press and hold Backspace for more than 1 frame.
It's a small consolation prize for this annoyance, getting to
tap-tap-tap Backspace in the hopes that you only press it for 1 frame,
while in the middle of something more important to do like, oh I don't
know, writing a script.
So there are two potential solutions here:
(1) Just change the frame ordering around.
This is risky to say the least, because I'm not sure what behavior
depends on exactly which frame order. It's not like it's key.Poll()
and then IMMEDIATELY afterwards editorinput() is run, it's more
like key.Poll(), some things that obviously depend on key.Poll()
running before them, and THEN editorinput(). Also, editorinput() is
only one possible thing that could be ran afterwards, on the next
frame we could be running something else entirely instead.
(2) Add a kludge variable to signal when the line is ALREADY empty so
the game doesn't re-check the already-empty line and conclude that
you're already immediately backspacing an empty line.
I went with (2) for this commit, and I've added the kludge variable
key.linealreadyemptykludge.
However, that by itself isn't enough to fix it. It only adds about a
frame or so of delay before the game goes right back to saying "Oh,
you're ALREADY somehow pressing backspace again? I'll just delete this
line real quick" and the behavior is basically the same as before,
except now you have to hit Backspace for TWO frames or less instead of
one in order to not have it happen.
What we need is to have a delay set as well, when the game deletes the
last line of a char. So I set ed.keydelay to 6 as well if editorinput()
sses that key.linealreadyemptykludge is on.
2020-01-19 03:17:46 +01:00
|
|
|
{
|
|
|
|
|
linealreadyemptykludge = true;
|
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
else if ( evt.key.keysym.sym == SDLK_v &&
|
|
|
|
|
keymap[SDLK_LCTRL] )
|
|
|
|
|
{
|
2021-03-31 08:23:29 +02:00
|
|
|
char* text = SDL_GetClipboardText();
|
|
|
|
|
if (text != NULL)
|
|
|
|
|
{
|
|
|
|
|
keybuffer += text;
|
|
|
|
|
SDL_free(text);
|
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_KEYUP:
|
2020-01-01 21:29:24 +01:00
|
|
|
keymap[evt.key.keysym.sym] = false;
|
|
|
|
|
if (evt.key.keysym.sym == SDLK_BACKSPACE)
|
|
|
|
|
{
|
|
|
|
|
pressedbackspace = false;
|
|
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_TEXTINPUT:
|
2020-08-13 03:08:25 +02:00
|
|
|
if (!altpressed)
|
2020-08-13 01:07:36 +02:00
|
|
|
{
|
|
|
|
|
keybuffer += evt.text.text;
|
|
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
/* Mouse Input */
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_MOUSEMOTION:
|
2020-01-01 21:29:24 +01:00
|
|
|
mx = evt.motion.x;
|
|
|
|
|
my = evt.motion.y;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_MOUSEBUTTONDOWN:
|
|
|
|
|
switch (evt.button.button)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_BUTTON_LEFT:
|
2020-01-01 21:29:24 +01:00
|
|
|
mx = evt.button.x;
|
|
|
|
|
my = evt.button.y;
|
|
|
|
|
leftbutton = 1;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_BUTTON_RIGHT:
|
2020-01-01 21:29:24 +01:00
|
|
|
mx = evt.button.x;
|
|
|
|
|
my = evt.button.y;
|
|
|
|
|
rightbutton = 1;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_BUTTON_MIDDLE:
|
2020-01-01 21:29:24 +01:00
|
|
|
mx = evt.button.x;
|
|
|
|
|
my = evt.button.y;
|
|
|
|
|
middlebutton = 1;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_MOUSEBUTTONUP:
|
|
|
|
|
switch (evt.button.button)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_BUTTON_LEFT:
|
2020-01-01 21:29:24 +01:00
|
|
|
mx = evt.button.x;
|
|
|
|
|
my = evt.button.y;
|
|
|
|
|
leftbutton=0;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_BUTTON_RIGHT:
|
2020-01-01 21:29:24 +01:00
|
|
|
mx = evt.button.x;
|
|
|
|
|
my = evt.button.y;
|
|
|
|
|
rightbutton=0;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_BUTTON_MIDDLE:
|
2020-01-01 21:29:24 +01:00
|
|
|
mx = evt.button.x;
|
|
|
|
|
my = evt.button.y;
|
|
|
|
|
middlebutton=0;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
/* Controller Input */
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_CONTROLLERBUTTONDOWN:
|
2020-01-01 21:29:24 +01:00
|
|
|
buttonmap[(SDL_GameControllerButton) evt.cbutton.button] = true;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_CONTROLLERBUTTONUP:
|
2020-01-01 21:29:24 +01:00
|
|
|
buttonmap[(SDL_GameControllerButton) evt.cbutton.button] = false;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_CONTROLLERAXISMOTION:
|
2020-11-13 02:16:18 +01:00
|
|
|
{
|
|
|
|
|
const int threshold = getThreshold();
|
2020-06-27 03:17:01 +02:00
|
|
|
switch (evt.caxis.axis)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_CONTROLLER_AXIS_LEFTX:
|
2020-11-13 02:16:18 +01:00
|
|
|
if ( evt.caxis.value > -threshold &&
|
|
|
|
|
evt.caxis.value < threshold )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
|
xVel = 0;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
xVel = (evt.caxis.value > 0) ? 1 : -1;
|
|
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_CONTROLLER_AXIS_LEFTY:
|
2020-11-13 02:16:18 +01:00
|
|
|
if ( evt.caxis.value > -threshold &&
|
|
|
|
|
evt.caxis.value < threshold )
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
|
yVel = 0;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
yVel = (evt.caxis.value > 0) ? 1 : -1;
|
|
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-11-13 02:16:18 +01:00
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_CONTROLLERDEVICEADDED:
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
|
SDL_GameController *toOpen = SDL_GameControllerOpen(evt.cdevice.which);
|
2021-02-24 00:21:29 +01:00
|
|
|
vlog_info(
|
|
|
|
|
"Opened SDL_GameController ID #%i, %s",
|
2020-01-01 21:29:24 +01:00
|
|
|
evt.cdevice.which,
|
|
|
|
|
SDL_GameControllerName(toOpen)
|
|
|
|
|
);
|
|
|
|
|
controllers[SDL_JoystickInstanceID(SDL_GameControllerGetJoystick(toOpen))] = toOpen;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_CONTROLLERDEVICEREMOVED:
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
|
SDL_GameController *toClose = controllers[evt.cdevice.which];
|
|
|
|
|
controllers.erase(evt.cdevice.which);
|
2021-02-24 00:21:29 +01:00
|
|
|
vlog_info("Closing %s", SDL_GameControllerName(toClose));
|
2020-01-01 21:29:24 +01:00
|
|
|
SDL_GameControllerClose(toClose);
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Window Events */
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_WINDOWEVENT:
|
|
|
|
|
switch (evt.window.event)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-06-27 03:17:01 +02:00
|
|
|
/* Window Resize */
|
|
|
|
|
case SDL_WINDOWEVENT_RESIZED:
|
2021-02-15 04:51:07 +01:00
|
|
|
if (SDL_GetWindowFlags(
|
|
|
|
|
SDL_GetWindowFromID(evt.window.windowID)
|
|
|
|
|
) & SDL_WINDOW_INPUT_FOCUS)
|
|
|
|
|
{
|
|
|
|
|
resetWindow = true;
|
|
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
/* Window Focus */
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_WINDOWEVENT_FOCUS_GAINED:
|
2020-06-30 04:49:14 +02:00
|
|
|
if (!game.disablepause)
|
|
|
|
|
{
|
|
|
|
|
isActive = true;
|
2021-08-19 05:50:02 +02:00
|
|
|
if ((!game.disableaudiopause || !game.disabletemporaryaudiopause) && music.currentsong != -1)
|
2021-08-05 21:20:05 +02:00
|
|
|
{
|
|
|
|
|
music.resume();
|
|
|
|
|
music.resumeef();
|
|
|
|
|
}
|
2020-06-30 04:49:14 +02:00
|
|
|
}
|
2021-04-05 17:07:32 +02:00
|
|
|
if (SDL_strcmp(SDL_GetCurrentVideoDriver(), "x11") == 0)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-06-13 16:35:05 +02:00
|
|
|
if (wasFullscreen)
|
|
|
|
|
{
|
2020-06-19 22:42:48 +02:00
|
|
|
graphics.screenbuffer->isWindowed = false;
|
2020-06-13 16:35:05 +02:00
|
|
|
SDL_SetWindowFullscreen(
|
|
|
|
|
SDL_GetWindowFromID(evt.window.windowID),
|
|
|
|
|
SDL_WINDOW_FULLSCREEN_DESKTOP
|
|
|
|
|
);
|
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
SDL_DisableScreenSaver();
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_WINDOWEVENT_FOCUS_LOST:
|
2021-03-31 21:12:13 +02:00
|
|
|
// For some reason, SDL_WINDOWEVENT_FOCUS_GAINED doesn't seem to get sent on Emscripten.
|
|
|
|
|
#ifndef __EMSCRIPTEN__
|
2020-06-30 04:49:14 +02:00
|
|
|
if (!game.disablepause)
|
|
|
|
|
{
|
|
|
|
|
isActive = false;
|
2021-08-12 03:08:32 +02:00
|
|
|
if (!game.disableaudiopause || !game.disabletemporaryaudiopause)
|
2021-08-05 21:20:05 +02:00
|
|
|
{
|
|
|
|
|
music.pause();
|
|
|
|
|
music.pauseef();
|
|
|
|
|
}
|
2020-06-30 04:49:14 +02:00
|
|
|
}
|
2021-03-31 21:12:13 +02:00
|
|
|
#endif
|
|
|
|
|
|
2021-04-05 17:07:32 +02:00
|
|
|
if (SDL_strcmp(SDL_GetCurrentVideoDriver(), "x11") == 0)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-06-19 22:42:48 +02:00
|
|
|
wasFullscreen = !graphics.screenbuffer->isWindowed;
|
|
|
|
|
graphics.screenbuffer->isWindowed = true;
|
2020-01-01 21:29:24 +01:00
|
|
|
SDL_SetWindowFullscreen(
|
|
|
|
|
SDL_GetWindowFromID(evt.window.windowID),
|
2020-06-13 16:35:05 +02:00
|
|
|
0
|
2020-01-01 21:29:24 +01:00
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
SDL_EnableScreenSaver();
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
/* Mouse Focus */
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_WINDOWEVENT_ENTER:
|
2020-01-01 21:29:24 +01:00
|
|
|
SDL_DisableScreenSaver();
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
|
case SDL_WINDOWEVENT_LEAVE:
|
2020-01-01 21:29:24 +01:00
|
|
|
SDL_EnableScreenSaver();
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
|
|
|
|
|
/* Quit Event */
|
2020-06-27 03:17:01 +02:00
|
|
|
case SDL_QUIT:
|
Call VVV_exit() when SDL_QUIT is received
This fixes a regression introduced by #535 where a quit signal (e.g.
Ctrl-C) sent to the window while the game was in unfocus pause wouldn't
close the game.
One problem was that key.quitProgram would only be checked when control
flow switched back to the outer loop in main(), which would only happen
when the loop order state machine switched to a delta function. As the
unfocused func table didn't have any delta functions, this means
key.quitProgram would never be checked.
So a naïve solution to this would just be to add a no-op delta func
entry to the unfocused func table. However, we then run into a separate
issue where a delta function at the end of a func list never reassigns
the active funcs, causing the game to be stuck in the unfocus pause
forever. Active func reassignment only happens after fixed funcs. So
then a naïve solution after that would be to simply add a no-op fixed
func entry after that. And indeed, that would fix the whole issue.
However, I want to do things the right way. And this does not seem like
the right way. Even putting aside the separate last-func-being-delta
issue, it mandates that every func list needs a delta function. Which
seems quite unnecessary to me.
Another solution I considered was copy-pasting the key.quitProgram check
to the inner loops, or adding some sort of signal propagation to
the inner loops - implemented by copy-pasting checks after each loop -
so we didn't need to copy-paste key.quitProgram... but that seems really
messy, too.
So, I realized that we could throw away key.quitProgram, and simply call
VVV_exit() directly when we receive an SDL_QUIT event. This fixes the
issue, this removes an unnecessary middleman variable, and it's pretty
cleanly and simply the right thing to do.
2021-04-02 00:24:14 +02:00
|
|
|
VVV_exit(0);
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2021-04-17 07:46:43 +02:00
|
|
|
|
|
|
|
|
switch (evt.type)
|
|
|
|
|
{
|
|
|
|
|
case SDL_KEYDOWN:
|
|
|
|
|
if (evt.key.repeat == 0)
|
|
|
|
|
{
|
|
|
|
|
hidemouse = true;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case SDL_TEXTINPUT:
|
|
|
|
|
case SDL_CONTROLLERBUTTONDOWN:
|
|
|
|
|
case SDL_CONTROLLERAXISMOTION:
|
|
|
|
|
hidemouse = true;
|
|
|
|
|
break;
|
|
|
|
|
case SDL_MOUSEMOTION:
|
|
|
|
|
case SDL_MOUSEBUTTONDOWN:
|
|
|
|
|
showmouse = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
2021-03-17 07:26:34 +01:00
|
|
|
|
2021-04-17 07:46:43 +02:00
|
|
|
mousetoggletimeout = changemousestate(
|
|
|
|
|
mousetoggletimeout,
|
|
|
|
|
showmouse,
|
|
|
|
|
hidemouse
|
|
|
|
|
);
|
|
|
|
|
|
2021-03-17 07:26:34 +01:00
|
|
|
if (fullscreenkeybind)
|
|
|
|
|
{
|
|
|
|
|
toggleFullscreen();
|
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool KeyPoll::isDown(SDL_Keycode key)
|
|
|
|
|
{
|
|
|
|
|
return keymap[key];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool KeyPoll::isDown(std::vector<SDL_GameControllerButton> buttons)
|
|
|
|
|
{
|
|
|
|
|
for (size_t i = 0; i < buttons.size(); i += 1)
|
|
|
|
|
{
|
|
|
|
|
if (buttonmap[buttons[i]])
|
|
|
|
|
{
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool KeyPoll::isDown(SDL_GameControllerButton button)
|
|
|
|
|
{
|
|
|
|
|
return buttonmap[button];
|
|
|
|
|
}
|
|
|
|
|
|
Explicitly declare void for all void parameter functions (#628)
Apparently in C, if you have `void test();`, it's completely okay to do
`test(2);`. The function will take in the argument, but just discard it
and throw it away. It's like a trash can, and a rude one at that. If you
declare it like `void test(void);`, this is prevented.
This is not a problem in C++ - doing `void test();` and `test(2);` is
guaranteed to result in a compile error (this also means that right now,
at least in all `.cpp` files, nobody is ever calling a void parameter
function with arguments and having their arguments be thrown away).
However, we may not be using C++ in the future, so I just want to lay
down the precedent that if a function takes in no arguments, you must
explicitly declare it as such.
I would've added `-Wstrict-prototypes`, but it produces an annoying
warning message saying it doesn't work in C++ mode if you're compiling
in C++ mode. So it can be added later.
2021-02-25 23:23:59 +01:00
|
|
|
bool KeyPoll::controllerButtonDown(void)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
|
for (
|
|
|
|
|
SDL_GameControllerButton button = SDL_CONTROLLER_BUTTON_A;
|
|
|
|
|
button < SDL_CONTROLLER_BUTTON_DPAD_UP;
|
|
|
|
|
button = (SDL_GameControllerButton) (button + 1)
|
|
|
|
|
) {
|
|
|
|
|
if (isDown(button))
|
|
|
|
|
{
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool KeyPoll::controllerWantsLeft(bool includeVert)
|
|
|
|
|
{
|
|
|
|
|
return ( buttonmap[SDL_CONTROLLER_BUTTON_DPAD_LEFT] ||
|
|
|
|
|
xVel < 0 ||
|
|
|
|
|
( includeVert &&
|
|
|
|
|
( buttonmap[SDL_CONTROLLER_BUTTON_DPAD_UP] ||
|
|
|
|
|
yVel < 0 ) ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool KeyPoll::controllerWantsRight(bool includeVert)
|
|
|
|
|
{
|
|
|
|
|
return ( buttonmap[SDL_CONTROLLER_BUTTON_DPAD_RIGHT] ||
|
|
|
|
|
xVel > 0 ||
|
|
|
|
|
( includeVert &&
|
|
|
|
|
( buttonmap[SDL_CONTROLLER_BUTTON_DPAD_DOWN] ||
|
|
|
|
|
yVel > 0 ) ) );
|
|
|
|
|
}
|
