and how many times are you loading textures from disk repeatedly
and how many times are you loading textures from disk repeatedly
Ain an open world game you can do it rather frequently
Rand most of the time even removing them from GPU
Aalso the performance is the gpu performance
Anot the loading performance
Rdepends on the Open world game
Rultimately for me doing it is not that big an issue.
KYour texture is also using more memory with no gain in quality. Data that's been uncompressed from a lossy format inherently stores useless information.
And that then eats into memory throughput & usage for no reason
And that then eats into memory throughput & usage for no reason
Rgood thing I don't use lossy formats
HThis is what I've been thinking of doing. Since that way it's easier to pack and I can automate most parts since i use a custom editor GUI app thingy. My game engine is 2d only for now and focuses on 2d. So i think i could do it in raw bytes yeah just for faster startup time (on final builds) but when in editor just load the raw PNGs or JPEGs or etc.
Halso most of my textures will be auto packed to single atlas or few atlases by the editor
Rafter all, if I am going to send an image in RGBA to the GPU, why would I create lossy versions of textures to store on disk
Abecause 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