2020-09-28 04:15:06 +02:00
|
|
|
#define HELP_DEFINITION
|
2020-01-01 21:29:24 +01:00
|
|
|
#include "UtilityClass.h"
|
|
|
|
|
2020-07-19 21:43:29 +02:00
|
|
|
#include <SDL.h>
|
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"
|
|
|
|
|
2021-02-07 22:03:33 +01:00
|
|
|
static const char* GCChar(const SDL_GameControllerButton button)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-02-07 22:05:24 +01:00
|
|
|
switch (button)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_A:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "A";
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_B:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "B";
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_X:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "X";
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_Y:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "Y";
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_BACK:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "BACK";
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_GUIDE:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "GUIDE";
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_START:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "START";
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_LEFTSTICK:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "L3";
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_RIGHTSTICK:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "R3";
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_LEFTSHOULDER:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "LB";
|
2021-02-07 22:05:24 +01:00
|
|
|
case SDL_CONTROLLER_BUTTON_RIGHTSHOULDER:
|
2020-01-01 21:29:24 +01:00
|
|
|
return "RB";
|
2021-02-07 22:05:24 +01:00
|
|
|
default:
|
|
|
|
SDL_assert(0 && "Unhandled button!");
|
|
|
|
return NULL;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-02-07 22:09:47 +01:00
|
|
|
int ss_toi(const std::string& str)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2021-02-07 22:09:47 +01:00
|
|
|
int retval = 0;
|
|
|
|
bool negative = false;
|
2021-02-08 06:17:57 +01:00
|
|
|
static const int radix = 10;
|
2021-02-07 22:09:47 +01:00
|
|
|
|
|
|
|
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))
|
|
|
|
{
|
2021-02-08 06:13:40 +01:00
|
|
|
retval *= radix;
|
2021-02-07 22:09:47 +01:00
|
|
|
retval += chr - '0';
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (negative)
|
|
|
|
{
|
|
|
|
return -retval;
|
|
|
|
}
|
|
|
|
|
|
|
|
return retval;
|
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(
|
|
|
|
size_t* start,
|
|
|
|
size_t* len,
|
|
|
|
const char* str,
|
|
|
|
const char delim
|
|
|
|
) {
|
|
|
|
size_t idx = 0;
|
|
|
|
*len = 0;
|
|
|
|
|
|
|
|
if (str[idx] == '\0')
|
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
|
|
|
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;
|
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(
|
|
|
|
char buffer[],
|
|
|
|
const size_t buffer_size,
|
|
|
|
size_t* start,
|
|
|
|
const char* str,
|
|
|
|
const char delim
|
|
|
|
) {
|
|
|
|
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, len);
|
|
|
|
SDL_memcpy(buffer, &str[prev_start], length);
|
|
|
|
buffer[length] = '\0';
|
|
|
|
}
|
|
|
|
|
|
|
|
return retval;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
UtilityClass::UtilityClass() :
|
|
|
|
glow(0),
|
|
|
|
glowdir(0)
|
|
|
|
{
|
2020-07-03 11:37:15 +02:00
|
|
|
for (size_t i = 0; i < SDL_arraysize(splitseconds); i++)
|
2020-01-01 21:29:24 +01:00
|
|
|
{
|
2020-07-03 11:37:15 +02:00
|
|
|
splitseconds[i] = (i * 100) / 30;
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
slowsine = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string UtilityClass::String( int _v )
|
|
|
|
{
|
|
|
|
std::ostringstream os;
|
|
|
|
os << _v;
|
|
|
|
return(os.str());
|
|
|
|
}
|
|
|
|
|
2020-08-07 06:56:35 +02:00
|
|
|
int UtilityClass::Int(const char* str, int fallback /*= 0*/)
|
2020-08-07 06:28:51 +02:00
|
|
|
{
|
|
|
|
if (!is_number(str))
|
|
|
|
{
|
2020-08-07 06:56:35 +02:00
|
|
|
return fallback;
|
2020-08-07 06:28:51 +02:00
|
|
|
}
|
|
|
|
|
2020-09-27 22:41:07 +02:00
|
|
|
return (int) SDL_strtol(str, NULL, 0);
|
2020-08-07 06:28:51 +02:00
|
|
|
}
|
|
|
|
|
2021-02-07 22:17:22 +01:00
|
|
|
std::string UtilityClass::GCString(const std::vector<SDL_GameControllerButton>& buttons)
|
2020-01-01 21:29:24 +01: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;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string UtilityClass::twodigits( int t )
|
|
|
|
{
|
|
|
|
if (t < 10)
|
|
|
|
{
|
|
|
|
return "0" + String(t);
|
|
|
|
}
|
|
|
|
if (t >= 100)
|
|
|
|
{
|
|
|
|
return "??";
|
|
|
|
}
|
|
|
|
return String(t);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string UtilityClass::timestring( int t )
|
|
|
|
{
|
|
|
|
//given a time t in frames, return a time in seconds
|
2020-04-03 00:05:41 +02:00
|
|
|
std::string tempstring = "";
|
2020-07-03 04:35:21 +02:00
|
|
|
int temp = (t - (t % 30)) / 30;
|
2020-01-01 21:29:24 +01:00
|
|
|
if (temp < 60) //less than one minute
|
|
|
|
{
|
|
|
|
t = t % 30;
|
|
|
|
tempstring = String(temp) + ":" + twodigits(splitseconds[t]);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2020-07-03 04:35:21 +02:00
|
|
|
int temp2 = (temp - (temp % 60)) / 60;
|
2020-01-01 21:29:24 +01:00
|
|
|
temp = temp % 60;
|
|
|
|
t = t % 30;
|
|
|
|
tempstring = String(temp2) + ":" + twodigits(temp) + ":" + twodigits(splitseconds[t]);
|
|
|
|
}
|
|
|
|
return tempstring;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string UtilityClass::number( int _t )
|
|
|
|
{
|
2020-07-03 11:37:53 +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"};
|
Abstract UtilityClass::number() to be more generic
Previously, it was a hardcoded list going up to fifty.
This time, it's less hardcoded. Most of the time, it will take a number,
find out its tens-place word, find out its ones-place word, and combine
the two together. There are special cases for the teens, and the numbers
zero through nine, and one hundred.
Also, now if it is given a negative value, it will just return "???"
instead.
If there are more than one hundred it will still say "Lots".
2020-01-23 15:45:50 +01:00
|
|
|
|
|
|
|
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];
|
|
|
|
}
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
bool UtilityClass::intersects( SDL_Rect A, SDL_Rect B )
|
|
|
|
{
|
2020-01-12 15:09:20 +01:00
|
|
|
return (SDL_HasIntersection(&A, &B) == SDL_TRUE);
|
2020-01-01 21:29:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void UtilityClass::updateglow()
|
|
|
|
{
|
|
|
|
slowsine++;
|
|
|
|
if (slowsine >= 64) slowsine = 0;
|
|
|
|
|
|
|
|
if (glowdir == 0) {
|
|
|
|
glow+=2;
|
|
|
|
if (glow >= 62) glowdir = 1;
|
|
|
|
}else {
|
|
|
|
glow-=2;
|
|
|
|
if (glow < 2) glowdir = 0;
|
|
|
|
}
|
|
|
|
}
|
2020-04-17 23:52:09 +02:00
|
|
|
|
2020-08-07 06:22:10 +02:00
|
|
|
bool is_number(const char* str)
|
|
|
|
{
|
|
|
|
for (int i = 0; str[i] != '\0'; i++)
|
|
|
|
{
|
2021-02-12 02:08:50 +01:00
|
|
|
if (!SDL_isdigit(str[i]) && (i != 0 || str[0] != '-'))
|
2020-08-07 06:22:10 +02:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
static bool VVV_isxdigit(const unsigned char digit)
|
|
|
|
{
|
|
|
|
return (digit >= 'a' && digit <= 'z')
|
|
|
|
|| (digit >= 'A' && digit <= 'Z')
|
|
|
|
|| SDL_isdigit(digit);
|
|
|
|
}
|
|
|
|
|
2021-02-12 01:36:22 +01:00
|
|
|
bool is_positive_num(const char* str, const bool hex)
|
2020-04-17 23:52:09 +02:00
|
|
|
{
|
2021-02-12 01:36:22 +01:00
|
|
|
for (size_t i = 0; str[i] != '\0'; ++i)
|
2020-04-17 23:52:09 +02:00
|
|
|
{
|
2020-06-16 02:31:54 +02:00
|
|
|
if (hex)
|
2020-04-17 23:52:09 +02:00
|
|
|
{
|
2021-02-12 01:26:12 +01:00
|
|
|
if (!VVV_isxdigit(str[i]))
|
2020-06-16 02:31:54 +02:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2021-02-12 01:26:12 +01:00
|
|
|
if (!SDL_isdigit(str[i]))
|
2020-06-16 02:31:54 +02:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2020-04-17 23:52:09 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
2020-06-21 23:25:23 +02:00
|
|
|
|
|
|
|
bool endsWith(const std::string& str, const std::string& suffix)
|
|
|
|
{
|
|
|
|
if (str.size() < suffix.size())
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return str.compare(
|
|
|
|
str.size() - suffix.size(),
|
|
|
|
suffix.size(),
|
|
|
|
suffix
|
|
|
|
) == 0;
|
|
|
|
}
|