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 <stdio.h>
|
|
|
|
#include <string.h>
|
2020-01-31 19:25:37 +01:00
|
|
|
#include <utf8/unchecked.h>
|
2020-01-01 21:29:24 +01:00
|
|
|
|
2020-07-19 21:43:29 +02:00
|
|
|
#include "Game.h"
|
|
|
|
#include "Graphics.h"
|
|
|
|
#include "Music.h"
|
|
|
|
|
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
|
|
|
|
|
|
|
quitProgram = 0;
|
|
|
|
keybuffer="";
|
|
|
|
leftbutton=0; rightbutton=0; middlebutton=0;
|
|
|
|
mx=0; my=0;
|
|
|
|
resetWindow = 0;
|
|
|
|
toggleFullscreen = false;
|
|
|
|
pressedbackspace=false;
|
|
|
|
|
|
|
|
useFullscreenSpaces = false;
|
Reduce dependency on libc functions
During 2.3 development, there's been a gradual shift to using SDL stdlib
functions instead of libc functions, but there are still some libc
functions (or the same libc function but from the STL) in the code.
Well, this patch replaces all the rest of them in one fell swoop.
SDL's stdlib can replace most of these, but its SDL_min() and SDL_max()
are inadequate - they aren't really functions, they're more like macros
with a nasty penchant for double-evaluation. So I just made my own
VVV_min() and VVV_max() functions and placed them in Maths.h instead,
then replaced all the previous usages of min(), max(), std::min(),
std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max().
Additionally, there's no SDL_isxdigit(), so I just implemented my own
VVV_isxdigit().
SDL has SDL_malloc() and SDL_free(), but they have some refcounting
built in to them, so in order to use them with LodePNG, I have to
replace the malloc() and free() that LodePNG uses. Which isn't too hard,
I did it in a new file called ThirdPartyDeps.c, and LodePNG is now
compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition.
Lastly, I also refactored the awful strcpy() and strcat() usages in
PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save
migration is getting axed in 2.4, but it still bothers me to have
something like that in the codebase otherwise.
Without further ado, here is the full list of functions that the
codebase now uses:
- SDL_strlcpy() instead of strcpy()
- SDL_strlcat() instead of strcat()
- SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above)
- VVV_min() instead of min(), std::min(), or SDL_min()
- VVV_max() instead of max(), std::max(), or SDL_max()
- VVV_isxdigit() instead of isxdigit()
- SDL_strcmp() instead of strcmp()
- SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi()
- SDL_strstr() instead of strstr()
- SDL_strlen() instead of strlen()
- SDL_sscanf() instead of sscanf()
- SDL_getenv() instead of getenv()
- SDL_malloc() instead of malloc() (replacing in LodePNG as well)
- SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
|
|
|
if (SDL_strcmp(SDL_GetPlatform(), "Mac OS X") == 0)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
|
|
|
useFullscreenSpaces = true;
|
|
|
|
const char *hint = SDL_GetHint(SDL_HINT_VIDEO_MAC_FULLSCREEN_SPACES);
|
|
|
|
if (hint != NULL)
|
|
|
|
{
|
Reduce dependency on libc functions
During 2.3 development, there's been a gradual shift to using SDL stdlib
functions instead of libc functions, but there are still some libc
functions (or the same libc function but from the STL) in the code.
Well, this patch replaces all the rest of them in one fell swoop.
SDL's stdlib can replace most of these, but its SDL_min() and SDL_max()
are inadequate - they aren't really functions, they're more like macros
with a nasty penchant for double-evaluation. So I just made my own
VVV_min() and VVV_max() functions and placed them in Maths.h instead,
then replaced all the previous usages of min(), max(), std::min(),
std::max(), SDL_min(), and SDL_max() with VVV_min() and VVV_max().
Additionally, there's no SDL_isxdigit(), so I just implemented my own
VVV_isxdigit().
SDL has SDL_malloc() and SDL_free(), but they have some refcounting
built in to them, so in order to use them with LodePNG, I have to
replace the malloc() and free() that LodePNG uses. Which isn't too hard,
I did it in a new file called ThirdPartyDeps.c, and LodePNG is now
compiled with the LODEPNG_NO_COMPILE_ALLOCATORS definition.
Lastly, I also refactored the awful strcpy() and strcat() usages in
PLATFORM_migrateSaveData() to use SDL_snprintf() instead. I know save
migration is getting axed in 2.4, but it still bothers me to have
something like that in the codebase otherwise.
Without further ado, here is the full list of functions that the
codebase now uses:
- SDL_strlcpy() instead of strcpy()
- SDL_strlcat() instead of strcat()
- SDL_snprintf() instead of sprintf(), strcpy(), or strcat() (see above)
- VVV_min() instead of min(), std::min(), or SDL_min()
- VVV_max() instead of max(), std::max(), or SDL_max()
- VVV_isxdigit() instead of isxdigit()
- SDL_strcmp() instead of strcmp()
- SDL_strcasecmp() instead of strcasecmp() or Win32 strcmpi()
- SDL_strstr() instead of strstr()
- SDL_strlen() instead of strlen()
- SDL_sscanf() instead of sscanf()
- SDL_getenv() instead of getenv()
- SDL_malloc() instead of malloc() (replacing in LodePNG as well)
- SDL_free() instead of free() (replacing in LodePNG as well)
2021-01-12 01:17:45 +01:00
|
|
|
useFullscreenSpaces = (SDL_strcmp(hint, "1") == 0);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
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
|
|
|
|
|
|
|
pauseStart = 0;
|
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;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
2020-08-13 03:08:25 +02:00
|
|
|
bool altpressed = 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
|
|
|
{
|
|
|
|
toggleFullscreen = true;
|
|
|
|
}
|
|
|
|
|
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] )
|
|
|
|
{
|
|
|
|
keybuffer += SDL_GetClipboardText();
|
|
|
|
}
|
|
|
|
}
|
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);
|
|
|
|
printf(
|
|
|
|
"Opened SDL_GameController ID #%i, %s\n",
|
|
|
|
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);
|
|
|
|
printf("Closing %s\n", SDL_GameControllerName(toClose));
|
|
|
|
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;
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
if (!useFullscreenSpaces)
|
|
|
|
{
|
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-30 04:49:14 +02:00
|
|
|
if (!game.disablepause && Mix_PlayingMusic())
|
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
|
|
|
{
|
|
|
|
// Correct songStart for how long we were paused
|
|
|
|
music.songStart += SDL_GetPerformanceCounter() - pauseStart;
|
|
|
|
}
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
|
|
|
case SDL_WINDOWEVENT_FOCUS_LOST:
|
2020-06-30 04:49:14 +02:00
|
|
|
if (!game.disablepause)
|
|
|
|
{
|
|
|
|
isActive = false;
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
if (!useFullscreenSpaces)
|
|
|
|
{
|
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-30 04:49:14 +02:00
|
|
|
if (!game.disablepause)
|
|
|
|
{
|
|
|
|
pauseStart = SDL_GetPerformanceCounter();
|
|
|
|
}
|
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:
|
2020-01-01 21:29:24 +01:00
|
|
|
quitProgram = true;
|
2020-06-27 03:17:01 +02:00
|
|
|
break;
|
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 ) ) );
|
|
|
|
}
|