vtfpp: byte order portability

[partyvan]

ok so in the process of fitting distance stuff into ImageConversion i became quite wary of the many reinterpret_cast<float *> kicking around, and sure enough, a small test program:

#include <vtfpp/vtfpp.h>

int
main(int argc, char *argv[])
{
	auto vtf = vtfpp::VTF::create(argv[1], vtfpp::VTF::CreationOptions{.outputFormat = vtfpp::ImageFormat::RGBA8888});
	auto rfmt = vtf.getFormat();
	auto rwidth = vtf.getWidth();
	auto rheight = vtf.getHeight();
	auto datas = vtf.getImageDataAs(rfmt);
	auto floaties = vtfpp::ImageConversion::convertImageDataToFormat(datas, rfmt, vtfpp::ImageFormat::RGBA32323232F, rwidth, rheight);
	auto opts = vtfpp::VTF::CreationOptions {.outputFormat = vtfpp::ImageFormat::RGBA32323232F};
	auto floatytex = vtfpp::VTF::create(floaties, vtfpp::ImageFormat::RGBA32323232F, rwidth, rheight, opts);
	auto success = floatytex.bake(std::endian::native == std::endian::big ? "from_be.vtf" : "from_le.vtf");

	return !success;
}

resulted in a nonsense vtf full of nans on my powerpc box. at time of writing, 33ebaec represents the absolute minimum it took to roundtrip correctly from img->tex on a big-endian machine to tex->img on a little-endian machine, by just invoking bufferstream's templates with enough information for its own byte order stuff to kick in.

question: in your opinion, is this something worth caring about? ot1h, who's running sourcepp on a BE machine in 2025 besides me for shits and giggles; otoh, it is technically billed as a general-purpose library, and depending on host byte order feels icky in such a setting. if it is something worth caring about, i could go up and down making sure any float/u16/etc reinterpretations do the appropriate shift/mask song and dance routine (ime, compilers are smart enough to emit equivalent assembly to reinterpret_cast on LE targets, and put registers in LE mode on bi-endian targets) so intermediate structures are always pc vtf output order by default, and chuck down some appropriate unit tests; if not, that's cool too.