depends what you want. storing it as bytes only will decrease the loading times but will largely increase the overall size. it's part of the reason a lot of games use DDS - decently small size, but doesn't take much to process since a lot of the decompression happens on the GPU.
personally if it's a small game I'd just recommend leaving it in the original format, unless all your textures are uncompressed anyway at which point yeah you might as well just store them as raw bytes
What does raw bytes mean? Straight RGBA8? Depending on the tech you're using I'd convert to some semi-compressed format that 90%+ of your target devices can load to GPU directly, with a software fallback ofc.
Fast decompression times, speed of parsing, and fast asset loading, and low storage size being a huge deal for those folks still with an HDD, and will make fetching off the disk significantly faster
You could go full for lack of a more professional term "balls to the walls" and create a glorified zip package, or virtual filesystem to minimize wasted space and ensure the maximum possible contiguous data storage. Leading to potentially a slightly smaller game and potentially being faster to load at the cost of not being as easy to edit and modify and being hidden away from users
is it decompressable on the gpu though? that's the real advantage of DDS and KTX. because they are stored compressed in vram you can fit a lot more textures in gpu memory, with the only caveat being that you get a bit of a reduction in image quality if you view the textures up close. can't say for 2D games, but for 3D games DDS or KTX with ST3-ST5 (idk what KTX uses, i think some khronos format) compressed textures is absolutely the format I would recommend any game ships with.
QOI looks like a neat image format but probably not one I would recommend for games, unless you don't plan to use GPU compressed textures at which point it seems like its a decent option
And really most people don't need GPU compressed textures, I don't even know of a good way to write them to disk from standard image formats (and I prefer being able to parse the texture data on the CPU side first anyway, so it does not really give me much to have GPU compressed textures I would then decompress lol)
yes, you do have to make some tradeoffs though if you want the most realistic looking game in the world then you'll probably have to use uncompressed textures, and then use sparse texturing on top of that if you want to load them all at once but for most usecases a bit of quality loss is fine
also from what i've seen gpu compressed textures are a bit faster as well since there's less data, both when it comes to drawing the texture itself and also transferring from cpu to vram
I need some help with assimp, I'm trying to limit bones used by meshes to 6 so I did this:
var ps = _assimp.CreatePropertyStore();
_assimp.SetImportPropertyInteger(ps, "PP_SBBC_MAX_BONES", 6);
var scene = _assimp.ImportFile(path, (uint)Assimp.PostProcessSteps.SplitByBoneCount);
var ps = _assimp.CreatePropertyStore();
_assimp.SetImportPropertyInteger(ps, "PP_SBBC_MAX_BONES", 6);
var scene = _assimp.ImportFile(path, (uint)Assimp.PostProcessSteps.SplitByBoneCount);
however meshes still have more than 6 bones, am I applying the property the wrong way?
var ps = _assimp.CreatePropertyStore();_assimp.SetImportPropertyInteger(ps, "PP_SBBC_MAX_BONES", 6);var scene = _assimp.ImportFile(path, (uint)Assimp.PostProcessSteps.SplitByBoneCount);
var ps = _assimp.CreatePropertyStore();_assimp.SetImportPropertyInteger(ps, "PP_SBBC_MAX_BONES", 6);var scene = _assimp.ImportFile(path, (uint)Assimp.PostProcessSteps.SplitByBoneCount);