because then you can upload it to the gpu in a compressed format so it uses less vram and gives a (s
because then you can upload it to the gpu in a compressed format so it uses less vram and gives a (slight) performance boost?
Rnot if I am going to uncompress it before loading it on GPU... like I previously stated would prefer to do...
Awhy would you do that though
Tfactorio compresses its texture atlases :)
Athere is literally 0 point in doing that
Ayea ive not seen compressed textures for 2D games but im assuming it can look okay
Rbecause I prefer having the textures in a format easily read on CPU and easily authored by myself
Abit like a jpeg
Ayou load in textures and make changes to them directly before uploading them to the gpu?
RIdeally yes. I would like to be able to stamp things on top of various textures
Ror at runtime generate textures to use.
RI would also not like to have to deal with a dozen variously compressed texture formats
Rand authoring said textures.
Tyou are argumenting as if one is not allowed to compress textures at runtime 
RI am arguing as though I don't want to deal with the overhead or dealing with compression/decompressing the textures at runtime
Tand the shaders get color values in the end regardless
Rboth in code or on my brain
Rand it ain't that slow.
Ajust wait until you are using many 4k textures in one scene and then you will be thankful that gpu compressed textures exist
RI have no plans on doing so
Rin most cases 4k textures are excessive, and also, that is why mipmapping exists
KEven with lossless it can still be compressed. Then I suppose you're not storing redundant information, but it's still inefficient for no reason
RI am not arguing about CPU side compression
K?
KCPUs Support lossless compressed textures as attachments and sometimes even for reading from compute
RI am saying I would like to be able to actually edit and modify my image data on the CPU side, my big thing is authoring and having compression and decompression codepaths.
KThe only advantage straight RGBA memory has is writing
Rto which that is my main reason for wanting to stay in RGBA
RI also don't want to deal with decompressing various different compression formats to get the RGBA textures out
Rnor a compression library to compress them initially
Twhy would you want to edit any texture at any time though
KI mean sure, if you need to edit it, I get it.
Fjust edit the texture ahead of time
RI want to paint
Fwhat
Rno but seriously
RI do want to be able to make changes to textures at runtime, mainly for runtime level editing and texture design.
RI would like to keep everything in game or at least in engine if possible
Tgpu-compressed textures are usually trivial to decompress, but you do you
RI looked into it, and they swirrled me into a headache pretty much instantly
Ror at least the DXT line did
Tthey would not be useful on the gpu if they were algorithmically difficult to decompress
Rnot to mention they each seem recommended for different common usecases, meaning I would probably want I think it was to support the main 3. Which pretty much made me threw my fist up.
RI never said anything about being algorithmically difficult
Treally now
Ryes
Rand I stand by what I said
KSo I'd highly recommend pushing readonly textures to GPU in BC/S3TC (same thing, two names) simply because memory is so slow and processors, especially GPU, are so fast.
KThe more modern the GPU is the larger the gap between CPU and memory speed. Not even mentioning mobile.
KThat's why pretty much all modern graphics apps use something like those, or even ASTC, to push readonly data to GPU
KAnd in 99% of cases textures are readonly