New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replaced all LINUX checks with __linux__ #4
base: master
Are you sure you want to change the base?
Conversation
Indeed LINUX is apparently a GCC extension, not sure about other compilers. If you don't mind me asking, why all the recent activity ? :) |
It's set by the build system, actually. Is there a need to change this? I need to check whether this affects FreeBSD. |
Yeah I did realise it's set by the build system, but that means the build system of any code that uses the library will need to set it, too, and only on Linux. Using linux seems to be more consistent since it checks for native preproc defines for windows and mac. If it's intended for all POSIX OSes, maybe POSIX would be a better name than "LINUX"? In any case, it's not a big issue and I'm happy to go without and just set it in my build system. @StanleySweet I've started writing a game based on 0ad assets :) they are all in DAE. Only the renderer is done so far, so not quite a game yet. |
Oh glad to see our assets put to use! I'm maintining the fcollada fork of 0 A.D. you might want to upstream vhanges from.there too. I will be integrating yours |
@StanleySweet Will take a look at that - thanks! I am converting all the DAEs ahead of time to my own FlatBuffers format so I don't need to support building/linking fcollada on all the platforms the game needs to run on (I imagine emscripten/web would be the worst!). That has made my life much easier so far. I'm guessing 0ad do the PMD/PSA conversion at runtime because of the live-reloading workflow for artists? |
It's in libraries/source/fcollada. We link against the system libxml2 and we don't require Devil anymore https://trac.wildfiregames.com/browser/ps/trunk/libraries/source/fcollada What's the advantage of the flat buffer format over another like assimp's one or Godot 's ? Yeah also cause we no longer have a pmd/psa exporter and nobody wrote a plugin :) |
@StanleySweet Ah that's awesome! I tried to use Assimp in the beginning, but it didn't parse many of the 0ad DAEs correctly (still not sure what's wrong, but a lot of strange scaling and rotations). Well, either Assimp is wrong or FCollada is wrong, but since I'm using 0ad assets, if FCollada is wrong I need to be wrong in the same way :). Assimp also does some really sketchy stuff with memory, and there have been attempts to build it for Emscripten, but there were always many plugins that either didn't build or produced corrupted results. The .ass format is much more complicated and I'd have to write a parser myself (since I don't want to link to Assimp). I have never looked into Godot, but it looks like they support importing from various formats, so it may be similar? FlatBuffers is nice because the compiler generates a portable header based on each schema, and that contains all the parsing and serializing code, with no dependency. Conceptually it's basically a thin wrapper around C structs to make them portable as a serialization format - it takes care of endianness, field sizes, alignment, padding, etc. So instead of loading DAEs or whatever and storing them in my game's in-memory structs, I just define those structs as schemas, and store my assets the way my game needs them. This also makes them very fast. For example, when I open a serialised FB with meshes in my game, the parsing code mmaps the file, and gives me pointers to vertex and index buffers within the file, and I can call glBufferData directly on that, so it's zero copy from page cache to GPU (well, at least to the GPU driver) on little-endian platforms. |
LINUX is not defined by default. linux is defined by at least GCC, Clang, and Android NDK: https://abseil.io/docs/cpp/platforms/macros