Getting this ported/working on Linux

[ghost]

"If you for some reason do want to build it on Linux or something feel free to get in touch I am happy to help point out what bits of the codebase are non-portable and what could be done."

Soooo...what bits of the codebase are non-portable and what can be done?

If it's relevant what my system is:

Distro --> Ubuntu 18.04.1 LTS Kernel --> 4.15.0-33-generic Graphics --> Nvidia GTX 750TI with 396.51 gcc --> version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)

[PrismaticFlower]

Hi, there shouldn't be too much that is non-portable. There are still probably a couple headaches though, the big one being DirectXTex which I'll explain after going through the easy stuff.

Firstly I'm lazy. And by that I mean I couldn't be bothered to use include guards and just used #pragma once. You're not wanting to compile this on some esoteric platform though so that shouldn't be a problem, I believe all major C++ compilers carry it as an extension.

Next the tool uses memory mapped files. I suspect it should be quite simple to create an implemntation of mapped_file that uses Linux apis.

The codebase has one unsafe use of reinterpret_cast in view_type_as that causes undefined behaviour. On Windows the desired thing always ends up happening so I never bothered to fix this. But I did abstract it away into a function so it could be replaced with a call to memcpy later if needed. However in all my great wisdom I stupidly made the return type be a reference, which obviously won't work with a memcpy.

Thankfully the return type is const so switching it away from a reference should be fairly simple and only as far as I know only two call sites depend on the result being a reference. Them being Ucfb_reader::read_trivial and Ucfb_reader::read_array respectively. I don't know how much (if any) code depends on the return type of read_array being a gsl::span instead of container but I imagine it shouldn't be too much. The real shame is that performance would be lost on having to do a heap allocation each time an array is read, but the tool seldoms takes long to run so that is probably moot.

It would probably be quicker to just pass -fno-strict-aliasing (I think that's it at least) to GCC and move on with life.

The hard part will be dealing with the dependencies. As far as I know glm and tbb should just build and work on Linux. DirectXTex however won't, not without a lot pain and tears at least. That means save_image, handle_texture, handle_texture_ps2 and handle_texture_xbox will have to be rewritten using a different library for image saving or removed outright. main.cpp also contains the function calls for initalizing COM that DirectXTex needs.

I'm not very familiar with imaging libraries but gli and libpng seem like they could be used together as a viable replacement. I'd probably personally just stub out the texture functions and focus on porting the rest of the tool first in any event.

I think that is about that. As I said the dependency on DirectXTex is probably the biggest hurdle to overcome. If you do end up trying to build it on Linux a go feel free to let me know what problems you encounter, I'd be curious to know what mistakes I made and how I could've written it to be more portable.

[ghost]

Hey, thank you for the run down!! I don't know when I'll get to writing a port b/c of several factors but I hope soon given I want to try and get Linux tool sets to mod SW: BF2 on my system. That being said, my C++ leaves much to be desired...sooooo.... Yeah. I'm gunna have to figure out the logic of the program and then per your helpful tips written here go from there. If it's written mostly in clean C++ I might just try compiling, see how things fail, and target them than try something else.

"I'd probably personally just stub out the texture functions and focus on porting the rest of the tool first in any event."

Agreed.