you are argumenting as if one is not allowed to compress textures at runtime 🙃
you 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
KSo...
Rnot gonna disagree
Ryou are 100% right
M Getting this on Linux running under Wayland, do i have to install anything else?
Rdo you have GLFW installed?
MInstalled the glfw-wayland package in Arch, and it fixed, but shouldnt silk.net include the libraries automatically?
MDidnt have, i thought it came with the nuget package
Rwhy? those are distro specific
Rand linux people like using their distros libraries
MI thought it was a standard library
Rwhy would GLFW be a standard library?
MWell by standard i meant as it should work on any linux distro, well i am new to linux so there are things that i dont know about libs/deps in linux space yet, in windows you could get a .dll for win8 and it should work on win11
MAnd there is a package called Ultz.Native.GLFW i thought it included all the libraries needed to run silk.net with glfw
