MinGW support

[ThisKwasior]

• Added return statements where there were none (hl_bina.h)
• We can directly specify the required static library in FindLZ4.cmake
• Overrides in hl_scene.cpp changed because it couldn't compile due to differences in declarations in fbxstream.h
• HedgeTools need to specify "%ls" for strings if unicode is requested
• HedgeRender was only tested with 2020.2.1 vs2019
• HedgeRender requires FBX_SHARED=True

To build in Msys2 MINGW64 shell:

$ pacman -S cmake git gcc mingw-w64-x86_64-robin-hood-hashing mingw-w64-x86_64-glm mingw-w64-x86_64-lz4 mingw-w64-x86_64-zlib mingw-w64-x86_64-glfw mingw-w64-x86_64-rapidjson
$ mkdir build && cd build
$ cmake .. -DFBX_SHARED=True
$ ninja

[Radfordhound]

Thanks a lot for the PR!

Just a few minor things I want to get resolved before I merge it in.

[Radfordhound]

These types are like this because they changed FbxStreams in FBX SDK version 2020.3.1 to add support for larger files (see commit ca9b1ef).

Can this SDK version, or any newer version, be used with MinGW?

If so, I would undo the changes to this file and just use that SDK version when compiling.

If not, then I'd say it'd be better to actually use typedefs based on the FBX SDK version being used?

Perhaps something like this in the in_fbx_stream_wrapper class?

#if FBXSDK_VERSION_MAJOR > 2020 || \
    (FBXSDK_VERSION_MAJOR == 2020 && FBXSDK_VERSION_MINOR > 3 || \
    (FBXSDK_VERSION_MINOR == 3 && FBXSDK_VERSION_POINT >= 1))
using out_size_t = size_t;
using in_size_t = FbxUInt64;
using pos_t = FbxInt64;
#else
using out_size_t = int;
using in_size_t = int;
using pos_t = long;
#endif

Then obviously change the definitions to use those typedefs:

out_size_t Write(const void* pData, in_size_t pSize) override
out_size_t Read(const void* pData, in_size_t pSize) override
pos_t GetPosition() const override
void SetPosition(pos_t pPosition) override

[ThisKwasior]

I have just checked against SDK 2020.3.1 vs2019 and it compiles fine with the original hl_scene.cpp, so yeah, I can agree my changes are redundant.
We can sure discard the changes here.

[Radfordhound]

I think this is a mistake? I'm trying to use the overload of std::string::assign which takes a begin and end iterator, where the types of both curNameSep + 1 and nextNameSep are const char*. Does this not compile in MinGW?

[ThisKwasior]

Sorry for not mentioning this one in the PR, must have slipped my mind.
Yes, it does not compile under MinGW, as auto in this case does not make it const char* as you think, but rather char* const&, which is weird as GCC and Clang on Linux have no problem here.
Didn't think about it before, but just hard typing it to be const char* instead of const auto resolves the issue as well.

[Radfordhound]

Does it work with other versions? If so, this can be removed.

If you don't want to check it that's fine, but honestly in that case I would also just remove this for now and just assume it works with any vs20XX version until proven otherwise.

[ThisKwasior]

It should work with any other version, but problem here does not lay in the FBX SDK itself, but detection of compilers.
Currently, the script checks for CMAKE_CXX_COMPILER_ID that's equal to MSVC, which isn't true for MinGW, as its ID is GNU.
Furthermore, it will fail again, as the latest version of GCC toolchain is 14.2.0 and not taken into account while checking MSVC versions.
FBX_INCLUDE_DIRS is being set just fine, but without the FBX_CP_PATH, it goes straight to here and returns.

HedgeLib/cmake/modules/FindFbx.cmake

Line 255 in a936b02

message("A Fbx installation was found, but couldn't be matched with current compiler settings.")