Fix CELL_GCM_TEXTURE_A8R8G8B8 outputs’ reversed channels

[hydnhntr]

path	broken	fixed
~/projects/gt5p/manual/GB/mage/gt5p/common/hot.dds
~/projects/gt5p/arcade/GB/mage/gt5p/icon/icon_dealer.dds

CELL_GCM_TEXTURE_A8R8G8B8 formatted TXS3 files were incorrectly output with their channels in reverse order.

The values of CELL_GCM_TEXTURE_REMAP_FROM looked correct to me, so the individual channels were already being read in their intended byte order.

Channel	CELL_GCM_TEXTURE_A8R8G8B8	Default values
InB	0	3
InG	1	2
InR	2	1
InA	3	0

I’m unsure what the manual endianness conversion was for, but with it removed A8R8G8B8 textures exported as expected. I don’t have an example of CELL_GCM_TEXTURE_D8R8G8B8 so don’t know if I’ve made a regression there 🫠

[Nenkai]

I don't completely remember why I added endian swap in the first place, but it must've been a good reason

Namely I believed that the pixel components in the pixel buffers are in big-endian according to PPC in the first place, regardless of remap

If you can, I would make sure that it works correctly across the majority of textures, namely i'd check GTHD, GT5P/5 and track textures

[hydnhntr]

Small update after looking at GTHD Concept’s UI textures:

Format	Output	Asset
DXT45		NPUA80019/project-ps3/image/component/ps3/cursor_chrome.dds
A8R8G8B8		NPUA80019/project-ps3/image/cursor/cursor_chrome.dds

cursors.zip

---

The uncompressed A8R8G8B8 version is currently ignoring the pitch, and includes the padding in the output.

I’m unsure how to handle this, whether to rejig the data inside CreateDDSData() or whether Pfimage can be passed a stride.

PDTools/PDTools.Files/Textures/PS3/PGLUCellTextureInfo.cs

Line 440 in 5bb714c

var i = Image.LoadPixelData<Bgra32>(dds.Data, (int)Utils.MiscUtils.AlignValue((uint)dds.Width, 4), dds.Height);

I also needed to remove the manual alignment above, as it was resulting in a mismatch in the expected length of data.