In a script I wish to draw pixels to an array which will later be attached to a texture using SetPixels, and eventually uploaded to the graphics card. Is it possible to pass compressed pixel data into SetPixels and thereby plot pixels to array by writing 1 byte per pixel rather than a Color (which I presume is 3 floats = 12 bytes)?
Just trying to figure out how to store the most amount of color data in main memory.
No; if you look in the docs you can see the parameters that SetPixels takes. You’d have to understand how DXT compression actually works anyway even if it was possible.
–Eric
A sort of workaround for this is to create your own compression format which allows pixels to be plotted quite quickly, keep it in main memory, then when it comes to uploading, convert/decompress the data into standard RGB/A color and then SetPixels(). A bit longwinded, and certainly extra overhead, but it works to save a lot of memory.
There is no replacement for compressed textures as compressed textures remain compressed on gpu.
any other format ends as “bmp sized” block on the gpu
You missed my point though. I was trying to write to a compressed texture stored in main memory in order to save on main memory. I know it can’t be uploaded to the gpu later but at least it’s possible to store texture data in a compressed format which is then transferred to an uncompressed texture in video ram - yes, takes up more video ram, but it does work for that special case.
You could store your textures temporarily in PNG format, which is not exactly state of the art, but still gives reasonable compression. The Texture2D class has two functions, EncodeToPNG and LoadImage which convert texture data to and from PNG format.
Hmm, interesting. How quick is the decompression? I’d need to do a few 256x256 images per frame.
Thats no problem, decompression is impact wise lightweight compared to the hit you will take from setpixels
Hmm, only trouble is, generating graphics at runtime would mean having to encode to PNG which is a slower process.
Well you can just as well not compress, then you don’t have the problem.
I would suspect that other parts are the much larger problem than having 300kb ram usage instead of 70kb 
No, actually that won’t work, I was planning to use a lot of ram, trying to fit it under 400 mb for a particular procedural level, and there is no way it’ll work without compression.
Well if your target is still those low end machines then I think it might become a MUST that you first benchmark the impact of it.
Its though obvious that on low end machines, it will be much heavier than on current machines which I assumed on aboves answer. (this also impacts Apply, which on those low end low bandwidth GPUs will run an ordner of magnitudes slower! so if you want realtime then ensure you keep it within 512x512 and smaller totalspace wise per frame if not lower depending on what you do otherwise)
Duly noted, thanks.