ARGB8888 is read by VTFLib as GBAR8888

[DBotThePony]

Sample file: argb8888.zip Expected, and in-game result: VTFEdit:

[thegrb93]

The way the channels are permutated look like the color data region is offsetted by two bytes.

[thegrb93]

The top-left and bottom-right pixel look fine though so maybe it's the channel mixing failing due to incorrect enum.

[thegrb93]

https://github.com/NeilJed/VTFLib/blob/ae19fcff1d4b5aa7e76ad3a69838f9fe77699d95/VTFLib/VTFFile.cpp#L3592-L3604 Mixing table looks fine at least

[thegrb93]

Enum here https://github.com/NeilJed/VTFLib/blob/f5e7991c92232111ca6e6e54aba130f43327cfd2/lib/VTFLib.h#L86-L101

[DBotThePony]

That's not something to do with offset, VTFLib straight swap color channels (even IF that's byte offset, then why it doesn't happen with ABGR8888?):

In-game test, topleft and bottomleft are textures loaded by game engine, first is correctly encoded ARGB8888 texture (using my implementation), second is VTFEdit ARGB8888 encoded texture. Second column is my implementation of VTF texture reader.

However, if i do next swap in my code from this

To this

Results are

argb8888_vtfedit.zip

[thegrb93]

Perhaps a bug with the shifts+masks in https://github.com/NeilJed/VTFLib/blob/ae19fcff1d4b5aa7e76ad3a69838f9fe77699d95/VTFLib/VTFFile.cpp#L3772

[thegrb93]

Attempted to debug but compiling on VS2019 is a no-go. Undefined references via DDS Utilities

[thegrb93]

I compared your vtf with one saved by vtf-edit. The image data in yours starts at D0 and vtf-edit's starts at CE which agrees with the 2-byte offset mentioned before.

Nevermind, checked the pixel values and vtf-edit's start at D0 too. Must be broken shifting+masking as mentioned before.