Split the test into several parametrised tests for each data type.
Add more tests with different values.
Fix the ReadBinary() function in order to fix the ReadDouble() function
for negative values (the sign bit was being lost).
Fail occurred due to wrong read of min double.
`unsigned long` has been changed in Write/ReadDouble functions to
`uint64_t`.
`unsigned int` has been changed in Write/ReadFloat functions to
`uint32_t`.
According to the standard
`int` is at least 16-bit so it might be too small for 32-bit `float`,
`long` is at least 32-bit so it might be too small for 64-bit `double`,
and `long long` is at least 64-bit.
Fix mistakes after previous merge and make it compile.
Rewrite the function interpolating between time stamps as it was
written after the original pull request was created. Add unit tests
for it.
I couldn't help myself and also changed some enums to enum classes and
did some renames.
There exists `CreateDirectory` `#define` somewhere and it results in
failed compilation of `resourcemanager.cpp`.
Similarly for `RemoveDirectory`. See
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createdirectorya
Rename the two methods to remove the conflict.
The fail occurs at least when using Visual Studio 2022 Preview.
* Added CBotStack::StackOver() calls where it was possible
to go out-of-bounds when calling CBotStack::AddStack().
* Fixed some bugs in CBotExternalCallClass
I moved m_engine creation to the constructor.
However, it is not complete until after calling m_engine->Create().
The UT segfault because the pointer is not null and destructor calls
m_engine->Destroy() on an incomplete object.
(Yes, UTs test incomplete SUT.)
So I moved back the m_engine creation to CApp::Create() but before
the SDL initialization as m_engine holds the flag for vsync.
The vsync may immediately fallback to another option after change from
the user so the UI should reflect that.
Todo: show a popup in UI informing the user why their desired vsync
option couldn't be set. Right now the error message is visible only from
the logs.
The issue is that the \button fragments in SatCom are replaced with
invalid UTF-8 bytes, hence those bytes need to be handled as a special
case when checking for UTF-8 character length.
When the text is processed e.g. in `Gfx::CText::Justify`, there are
generally two arrays: `text` and `format`. The second one is interpreted
as a font for a given character, e.g. `text[i]` has font `format[i]`.
Now, in the loops the index for `text` is increased by the length of
the character, e.g. 1 to 4 bytes, whereas index for `format` is
only incremented. It seems there's an assumption that `format` treats
multibyte characters as one byte, which doesn't seem to be true by
looking at the process of filling up the `format` array. This can result
in using wrong font e.g. FONT_SATCOM for the \button character which
should be FONT_BUTTON, hence the `StrUtils::Utf8CharSizeAt` method
complains about unexpected continuation byte via exception, causing
the crash.
Incrementing the index by the UTF-8 length seems to have fixed the
issue. However, I am not sure if I haven't broken anything else by this
and if I analyzed the intended behaviour correctly.
Gfx::CText needs a major refactor IMHO.
Signed-off-by: suve <veg@svgames.pl>
Jeff's patch was written for the 0.1.12 stable release.
Adapted to work with the "dev" branch (as of commit 13098ee).
This fixes the issue with objects and terrain being darker than they should be. As it turns out, most levels have not normalized light direction which happens to make light brighter and this is the expected result. To keep in line with GL14 engine, newer engines should use the length of the vector to make light brighter.
MrSimbax