PNG Loader missing from basegame

[ZNixian]

When using custom textures, calling DB:reload_textures does not seem to do anything - this is very likely a caching issue.

[RomanHargrave]

The next logical step is to actually look at the code path for Linux and Windows and see how they differ.

[ZNixian]

Ah, I just realized something - VoidUI (which works) uses .texture (dds) images, while the mod icons use PNGs. I'll see if using DDS makes the mod icons show up.

[ZNixian]

Ah, that does seem to be the issue. The windows binary contains LibPNG, while the GNU+Linux binary does not.

[ZNixian]

As a note, TGA images do load successfully - they are the only format (besides DDS) supported in the basegame.

It appears one way to implement this is to create a subclass of DSL::ImageParser

Edit: VTable for easy reference:

sym vtable for dsl::ImageParser = 0x137a170 (size = 160)
    ... entries:    20
0       (int (*)(...)) 0
8      (int (*)(...)) (& typeinfo for dsl::ImageParser)
16      (int (*)(...)) (& dsl::ImageParser::~ImageParser())
24      (int (*)(...)) (& dsl::ImageParser::~ImageParser())
32      (int (*)(...)) (& dsl::ImageParser::is_type(unsigned int) const)
40      (int (*)(...)) (& dsl::ImageParser::type_id() const)
48      (int (*)(...)) (& dsl::ImageProducer::open())
56      (int (*)(...)) (& dsl::ImageProducer::close())
64      (int (*)(...)) __cxa_pure_virtual
72      (int (*)(...)) __cxa_pure_virtual
80      (int (*)(...)) __cxa_pure_virtual
88      (int (*)(...)) (& dsl::ImageProducer::slices() const)
96      (int (*)(...)) (& dsl::ImageProducer::set_slice(int))
104      (int (*)(...)) (& dsl::ImageProducer::srgb() const)
112      (int (*)(...)) __cxa_pure_virtual
(int (*)(...)) -0x00000000000008
128      (int (*)(...)) (& typeinfo for dsl::ImageParser)
136      (int (*)(...)) (& non-virtual thunk to dsl::ImageParser::~ImageParser())
144      (int (*)(...)) (& non-virtual thunk to dsl::ImageParser::~ImageParser())

[RomanHargrave]

I'm surprised the game doesn't have a PNG decoder somewhere. It would be idea if we didn't have to bring one with us, should we implement this.

The other problem that this brings up is the inevitable libcxx nightmare.

[ZNixian]

I'm surprised the game doesn't have a PNG decoder somewhere. It would be idea if we didn't have to bring one with us,

Since it's only loading DDL encoded images from the asset bundles, there isn't really anything they need the PNG loader for.

On Windows they use it for development reasons (and ship it for some reason), but not during normal use of the game.

should we implement this.

Given that almost every mod with custom images uses PNG, it's probably a good idea.

The other problem that this brings up is the inevitable libcxx nightmare.

IIRC DB:create_entry requires libcxx anyway, so that's not any more of an issue than it is currently. Having said that, skimming though assets.cc I can only see std::string being used, so we might be able to make a tiny reimplementation of libcxx's string class and use that on GCC.

[RomanHargrave]

I had considered reimplementing std::string but run in to something that turned me off of that - I'm not quite sure what it was (though if I had to guess, it was the need to reimplement many containers as well). That being said, if the license is compatible, we also have the option of 'transplanting' it.

[RomanHargrave]

@ZNixian i've decided to start a project branch to investigate and implement a 'port' of libcxx (mainly re-namespacing), specifically the parts we want. If it becomes unweildy but useful, we can extract it to its own repository.

Luckily, libcxx is quite small (deceiving, though, we are talking about C++ after all) compared to a monster like boost, so I would hope we can start to see success soon.

[ZNixian]

IIRC all we really need is std::string and std::vector, if that helps.

It'd certainly be very nice to get away from requiring libcxx.

PS Have you had a look at SuperBLT, and in particular it's GNU+Linux support? If so, do you have any thoughts about it?

[RomanHargrave]

When did it get gnu/Linux support?

[RomanHargrave]

Misread that. I'll have to look at it a bit more tomorrow.

[RomanHargrave]

We can probably merge that @ZNixian if it is working. Is there s bullet list of roadblocks?