mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-11-05 10:49:41 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/UtilityClass.cpp

355 lines
7 KiB
C++
Raw Normal View History

Clean up and prevent unnecessary qualifiers to self By "unnecessary qualifiers to self", I mean something like using the 'game.' qualifier for a variable on the Game class when you're inside a function on the Game class itself. This patch is to enforce consistency as most of the code doesn't have these unnecessary qualifiers. To prevent further unnecessary qualifiers to self, I made it so the extern in each header file can be omitted by using a define. That way, if someone writes something referring to 'game.' on a Game function, there will be a compile error. However, if you really need to have a reference to the global name, and you're within the same .cpp file as the implementation of that object, you can just do the extern at the function-level. A good example of this is editorinput()/editorrender()/editorlogic() in editor.cpp. In my opinion, they should probably be split off into their own separate file because editor.cpp is getting way too big, but this will do for now.
2020-09-28 04:15:06 +02:00
#define HELP_DEFINITION
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include "UtilityClass.h"
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:43:29 +02:00
#include <SDL.h>
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
#include <sstream>
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
#include "Maths.h"
Add constness to GCChar() input and switch position of asterisk I personally like putting the asterisk with the type, because despite the language parsing the asterisk as a part of the name, the pointer part is clearly a part of the return type of the function. Also, put constness here, to indicate that the input won't be modified inside the function.
2021-02-07 22:03:33 +01:00
static const char* GCChar(const SDL_GameControllerButton button)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
switch (button)
{
case SDL_CONTROLLER_BUTTON_A:
return "A";
case SDL_CONTROLLER_BUTTON_B:
return "B";
case SDL_CONTROLLER_BUTTON_X:
return "X";
case SDL_CONTROLLER_BUTTON_Y:
return "Y";
case SDL_CONTROLLER_BUTTON_BACK:
return "BACK";
case SDL_CONTROLLER_BUTTON_GUIDE:
return "GUIDE";
case SDL_CONTROLLER_BUTTON_START:
return "START";
case SDL_CONTROLLER_BUTTON_LEFTSTICK:
return "L3";
case SDL_CONTROLLER_BUTTON_RIGHTSTICK:
return "R3";
case SDL_CONTROLLER_BUTTON_LEFTSHOULDER:
return "LB";
case SDL_CONTROLLER_BUTTON_RIGHTSHOULDER:
return "RB";
default:
SDL_assert(0 && "Unhandled button!");
return NULL;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Refactor ss_toi() to not use stringstreams Apart from the std::string, this function no longer uses the STL. ss_toi() is a simple function - it converts the input into an int, taking as many digits as possible until it reaches a non-digit character, at which point it stops. It's trivial to implement this without the STL. I could've used Int() here, but that would've required copying the string to a temporary buffer to insert a null-terminator (we can't just use a pointer-and-length data type either, the string functions don't operate like that - one disadvantage of C strings!). Instead, I decided to implement my own conversion to int here, because I don't think the way we humans write our Arabic numerals is going to change anytime soon. Also, the std::string input is now passed by const reference, instead of making a copy - cutting down on unnecessary memory operations.
2021-02-07 22:09:47 +01:00
int ss_toi(const std::string& str)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
int retval = 0;
bool negative = false;
static const int radix = 10;
for (size_t i = 0; i < str.size(); ++i)
{
const char chr = str[i];
if (i == 0 && chr == '-')
{
negative = true;
continue;
}
if (SDL_isdigit(chr))
{
retval *= radix;
retval += chr - '0';
}
else
{
break;
}
}
if (negative)
{
return -retval;
}
return retval;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
bool next_split(
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
size_t* start,
size_t* len,
const char* str,
const char delim
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
) {
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
size_t idx = 0;
*len = 0;
if (str[idx] == '\0')
{
return false;
}
while (true)
{
if (str[idx] == delim)
{
*start += 1;
return true;
}
else if (str[idx] == '\0')
{
return true;
}
idx += 1;
*start += 1;
*len += 1;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
bool next_split_s(
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
char buffer[],
const size_t buffer_size,
size_t* start,
const char* str,
const char delim
Refactor loading arrays from XML to not use the STL The current way "arrays" from XML files are loaded (before this commit is applied) goes something like this: 1. Read the buffer of the contents of the tag using TinyXML-2. 2. Allocate a buffer on the heap of the same size, and copy the existing buffer to it. (This is what the statement `std::string TextString = pText;` does.) 3. For each delimiter in the heap-allocated buffer... a. Allocate another buffer on the heap, and copy the characters from the previous delimiter to the delimiter you just hit. b. Then allocate the buffer AGAIN, to copy it into an std::vector. 4. Then re-allocate every single buffer YET AGAIN, because you need to make a copy of the std::vector in split() to return it to the caller. As you can see, the existing way uses a lot of memory allocations and data marshalling, just to split some text. The problem here is mostly making a temporary std::vector of split text, before doing any actual useful work (most likely, putting it into an array or ANOTHER std::vector - if the latter, then that's yet another memory allocation on top of the memory allocation you already did; this memory allocation is unavoidable, unlike the ones mentioned earlier, which should be removed). So I noticed that since we're iterating over the entire string once (just to shove its contents into a temporary std::vector), and then basically iterating over it again - why can't the whole thing just be more immediate, and just be iterated over once? So that's what I've done here. I've axed the split() function (both of them, actually), and made next_split() and next_split_s(). next_split() will take an existing string and a starting index, and it will find the next occurrence of the given delimiter in the string. Once it does so, it will return the length from the previous starting index, and modify your starting index as well. The price for immediateness is that you're supposed to handle keeping the index of the previous starting index around in order to be able to use the function; updating it after each iteration is also your responsibility. (By the way, next_split() doesn't use SDL_strchr(), because we can't get the length of the substring for the last substring. We could handle this special case specifically, but it'd be uglier; it also introduces iterating over the last substring twice, when we only need to do it once.) next_split_s() does the same thing as next_split(), except it will copy the resulting substring into a buffer that you provide (along with its size). Useful if you don't particularly care about the length of the substring. All callers have been updated accordingly. This new system does not make ANY heap allocations at all; at worst, it allocates a temporary buffer on the stack, but that's only if you use next_split_s(); plus, it'd be a fixed-size buffer, and stack allocations are negligible anyway. This improves performance when loading any sort of XML file, especially loading custom levels - which, on my system at least, I can noticeably tell (there's less of a freeze when I load in to a custom level with lots of scripts). It also decreases memory usage, because the heap isn't being used just to iterate over some delimiters when XML files are loaded.
2021-02-13 01:37:29 +01:00
) {
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
size_t len = 0;
const size_t prev_start = *start;
const bool retval = next_split(start, &len, &str[*start], delim);
if (retval)
{
/* Using SDL_strlcpy() here results in calling SDL_strlen() */
/* on the whole string, which results in a visible freeze */
/* if it's a very large string */
const size_t length = VVV_min(buffer_size - 1, len);
SDL_memcpy(buffer, &str[prev_start], length);
buffer[length] = '\0';
}
return retval;
Hello WWWWWWorld!
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
UtilityClass::UtilityClass(void) :
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
glow(0),
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
glowdir(0)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
for (size_t i = 0; i < SDL_arraysize(splitseconds); i++)
{
splitseconds[i] = (i * 100) / 30;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
slowsine = 0;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
std::string UtilityClass::String( int _v )
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
std::ostringstream os;
os << _v;
return(os.str());
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add fallback parameter to UtilityClass::Int() If necessary, the caller can provide a fallback to be returned in case the input given isn't a valid integer, instead of having to duplicate the is_number() check.
2020-08-07 06:56:35 +02:00
int UtilityClass::Int(const char* str, int fallback /*= 0*/)
Add UtilityClass::Int() This is simply a wrapper function around SDL_atoi(), because SDL_atoi() could call libc atoi(), and whether or not invalid input passed into the libc atoi() is undefined behavior depends on the given libc. So it's safer to just add a wrapper function that checks that the string given isn't bogus.
2020-08-07 06:28:51 +02:00
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
if (!is_number(str))
{
return fallback;
}
Add UtilityClass::Int() This is simply a wrapper function around SDL_atoi(), because SDL_atoi() could call libc atoi(), and whether or not invalid input passed into the libc atoi() is undefined behavior depends on the given libc. So it's safer to just add a wrapper function that checks that the string given isn't bogus.
2020-08-07 06:28:51 +02:00
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
return (int) SDL_strtol(str, NULL, 0);
Add UtilityClass::Int() This is simply a wrapper function around SDL_atoi(), because SDL_atoi() could call libc atoi(), and whether or not invalid input passed into the libc atoi() is undefined behavior depends on the given libc. So it's safer to just add a wrapper function that checks that the string given isn't bogus.
2020-08-07 06:28:51 +02:00
}
Pass input of UtilityClass::GCString() by const reference This avoids an unnecessary copy of the input std::vector, since we don't need to modify it for anything. This cuts down on unnecessary memory operations.
2021-02-07 22:17:22 +01:00
std::string UtilityClass::GCString(const std::vector<SDL_GameControllerButton>& buttons)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
std::string retval = "";
for (size_t i = 0; i < buttons.size(); i += 1)
{
retval += GCChar(buttons[i]);
if ((i + 1) < buttons.size())
{
retval += ",";
}
}
return retval;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
std::string UtilityClass::twodigits( int t )
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
if (t < 10)
{
return "0" + String(t);
}
if (t >= 100)
{
return "??";
}
return String(t);
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
std::string UtilityClass::timestring( int t )
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
//given a time t in frames, return a time in seconds
std::string tempstring = "";
int temp = (t - (t % 30)) / 30;
if (temp < 60) //less than one minute
{
t = t % 30;
tempstring = String(temp) + ":" + twodigits(splitseconds[t]);
}
else
{
int temp2 = (temp - (temp % 60)) / 60;
temp = temp % 60;
t = t % 30;
tempstring = String(temp2) + ":" + twodigits(temp) + ":" + twodigits(splitseconds[t]);
}
return tempstring;
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
std::string UtilityClass::number( int _t )
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
static const std::string ones_place[] = {"One", "Two", "Three", "Four", "Five", "Six", "Seven", "Eight", "Nine"};
static const std::string tens_place[] = {"Ten", "Twenty", "Thirty", "Forty", "Fifty", "Sixty", "Seventy", "Eighty", "Ninety"};
static const std::string teens[] = {"Eleven", "Twelve", "Thirteen", "Fourteen", "Fifteen", "Sixteen", "Seventeen", "Eighteen", "Nineteen"};
if (_t < 0)
{
return "???";
}
else if (_t > 100)
{
return "Lots";
}
else if (_t == 0)
{
return "Zero";
}
else if (_t == 100)
{
return "One Hundred";
}
else if (_t >= 1 && _t <= 9)
{
return ones_place[_t-1];
}
else if (_t >= 11 && _t <= 19)
{
return teens[_t-11];
}
else if (_t % 10 == 0)
{
return tens_place[(_t/10)-1];
}
else
{
return tens_place[(_t/10)-1] + " " + ones_place[(_t%10)-1];
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
bool UtilityClass::intersects( SDL_Rect A, SDL_Rect B )
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
return (SDL_HasIntersection(&A, &B) == SDL_TRUE);
Hello WWWWWWorld!
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 UtilityClass::updateglow(void)
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
slowsine++;
if (slowsine >= 64) slowsine = 0;
if (glowdir == 0) {
glow+=2;
if (glow >= 62) glowdir = 1;
}else {
glow-=2;
if (glow < 2) glowdir = 0;
}
Hello WWWWWWorld!
2020-01-01 21:29:24 +01:00
}
Add is_positive_num() to UtilityClass.cpp This is a convenience function to tell if a string is not only a number (and can thus be passed into atoi()), but is also positive in particular.
2020-04-17 23:52:09 +02:00
Add is_number() This will be used to check if a string is a valid integer. So negative numbers are accepted, unlike is_positive_num().
2020-08-07 06:22:10 +02:00
bool is_number(const char* str)
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
if (!SDL_isdigit(str[0]) && str[0] != '-')
{
return false;
}
if (str[0] == '-' && str[1] == '\0')
{
return false;
}
for (size_t i = 1; str[i] != '\0'; ++i)
{
if (!SDL_isdigit(str[i]))
{
return false;
}
}
return true;
Add is_number() This will be used to check if a string is a valid integer. So negative numbers are accepted, unlike is_positive_num().
2020-08-07 06:22:10 +02:00
}
Refactor is_positive_num() to use C-strings This makes the future move to C easier, as well as just shows that it's plain unnecessary to use an std::string here.
2021-02-12 01:36:22 +01:00
bool is_positive_num(const char* str, const bool hex)
Add is_positive_num() to UtilityClass.cpp This is a convenience function to tell if a string is not only a number (and can thus be passed into atoi()), but is also positive in particular.
2020-04-17 23:52:09 +02:00
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
if (str[0] == '\0')
{
return false;
}
for (size_t i = 0; str[i] != '\0'; ++i)
{
if (hex)
{
Use `SDL_isxdigit()` in favor of `VVV_isxdigit()` SDL_isxdigit() was added in SDL 2.0.16, so we no longer have to implement isxdigit() ourselves.
2021-08-19 07:28:58 +02:00
if (!SDL_isxdigit(str[i]))
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
{
return false;
}
}
else
{
if (!SDL_isdigit(str[i]))
{
return false;
}
}
}
return true;
Add is_positive_num() to UtilityClass.cpp This is a convenience function to tell if a string is not only a number (and can thus be passed into atoi()), but is also positive in particular.
2020-04-17 23:52:09 +02:00
}
Move endsWith() to UtilityClass.cpp and put it in header file This ensures that endsWith() can be used outside of editor.cpp. When leo60228 originally wrote endsWith(), it was static, but I asked him on Discord just now and he more-or-less confirmed that it's fine if it's not static. If it was static, it would be confined to UtilityClass.cpp now instead!
2020-06-21 23:25:23 +02:00
Refactor endsWith() to not use the STL There's not really any reason for this function to use heap-allocated strings. So I've refactored it to not do that. I would've used SDL_strrstr(), if it existed. It does not appear to exist. But that's okay.
2021-02-27 00:29:37 +01:00
bool endsWith(const char* str, const char* suffix)
Move endsWith() to UtilityClass.cpp and put it in header file This ensures that endsWith() can be used outside of editor.cpp. When leo60228 originally wrote endsWith(), it was static, but I asked him on Discord just now and he more-or-less confirmed that it's fine if it's not static. If it was static, it would be confined to UtilityClass.cpp now instead!
2020-06-21 23:25:23 +02:00
{
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
const size_t str_size = SDL_strlen(str);
const size_t suffix_size = SDL_strlen(suffix);
Refactor endsWith() to not use the STL There's not really any reason for this function to use heap-allocated strings. So I've refactored it to not do that. I would've used SDL_strrstr(), if it existed. It does not appear to exist. But that's okay.
2021-02-27 00:29:37 +01:00
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
if (str_size < suffix_size)
{
return false;
}
Refactor endsWith() to not use the STL There's not really any reason for this function to use heap-allocated strings. So I've refactored it to not do that. I would've used SDL_strrstr(), if it existed. It does not appear to exist. But that's okay.
2021-02-27 00:29:37 +01:00
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
return SDL_strcmp(&str[str_size - suffix_size], suffix) == 0;
Move endsWith() to UtilityClass.cpp and put it in header file This ensures that endsWith() can be used outside of editor.cpp. When leo60228 originally wrote endsWith(), it was static, but I asked him on Discord just now and he more-or-less confirmed that it's fine if it's not static. If it was static, it would be confined to UtilityClass.cpp now instead!
2020-06-21 23:25:23 +02:00
}
Add VVV_fillstring() This function is simple - it takes a given buffer and its size, fills it with a certain character, and null-terminates it. It's meant to be used with freshly-created buffers, so we don't copy-paste code.
2021-04-12 02:19:53 +02:00
void VVV_fillstring(
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
char* buffer,
const size_t buffer_size,
const char fillchar
Add VVV_fillstring() This function is simple - it takes a given buffer and its size, fills it with a certain character, and null-terminates it. It's meant to be used with freshly-created buffers, so we don't copy-paste code.
2021-04-12 02:19:53 +02:00
) {
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
SDL_memset(buffer, fillchar, buffer_size - 1);
buffer[buffer_size - 1] = '\0';
Add VVV_fillstring() This function is simple - it takes a given buffer and its size, fills it with a certain character, and null-terminates it. It's meant to be used with freshly-created buffers, so we don't copy-paste code.
2021-04-12 02:19:53 +02:00
}
Factor out "between" calculation to macro and func FILESYSTEM_mountAssets() has a big comment describing the magic numbers needed to grab FILENAME from a string that looks like "levels/FILENAME.vvvvvv". Instead of doing that (and having to write a comment every time the similar happens), I've written a macro (and helper function) instead that does the same thing, but clearly conveys the intent. I mean, just look at the diff. Using VVV_between() is much better than having to read that comment, and the corresponding SDL_strlcpy().
2021-05-20 23:14:08 +02:00
void _VVV_between(
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
const char* original,
const size_t left_length,
char* middle,
const size_t right_length,
const size_t middle_size
Factor out "between" calculation to macro and func FILESYSTEM_mountAssets() has a big comment describing the magic numbers needed to grab FILENAME from a string that looks like "levels/FILENAME.vvvvvv". Instead of doing that (and having to write a comment every time the similar happens), I've written a macro (and helper function) instead that does the same thing, but clearly conveys the intent. I mean, just look at the diff. Using VVV_between() is much better than having to read that comment, and the corresponding SDL_strlcpy().
2021-05-20 23:14:08 +02:00
) {
Untabify every single file YOLO. This is a repeat of #642. As before, I just did rg -l '\t' | xargs -n 1 sed -i -e 's/\t/ /g' inside the desktop_version/ folder.
2021-09-07 03:56:39 +02:00
size_t middle_length = SDL_strlen(original);
middle_length -= left_length + right_length;
SDL_strlcpy(
middle,
&original[left_length],
VVV_min(middle_length + 1, middle_size)
);
Factor out "between" calculation to macro and func FILESYSTEM_mountAssets() has a big comment describing the magic numbers needed to grab FILENAME from a string that looks like "levels/FILENAME.vvvvvv". Instead of doing that (and having to write a comment every time the similar happens), I've written a macro (and helper function) instead that does the same thing, but clearly conveys the intent. I mean, just look at the diff. Using VVV_between() is much better than having to read that comment, and the corresponding SDL_strlcpy().
2021-05-20 23:14:08 +02:00
}
Reference in a new issue Copy permalink