Does C3 support DXT compressed textures on WebGL?

I was just learning that textures can be compressed on the GPU. And that the GPU can decompresses them efficiently at runtime. It appears it can drastically reduce GPU memory, so that much larger textures can be used than normally wouldn't be possible.

It looks like WebGL supports them: developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Compressed_texture_formats

I was wondering if C3 supports these types of textures? Or ever will in the future?

I see. Thanks for the insight Ashely. I agree about clean pixel art games, you definitely don't want to do any lossy compression there. But I thought it might allow users to create higher resolution 2D games in C3 without hogging so much memory. Like Machinarium which has unique backgrounds for every screen. Almost zero screens have repeated elements.

I got inspired by the video in the link below. It's a guy making a really high resolution 2D game in Unity. He uses like 4k textures even for simple background/foreground decorations that are 18MB each. But Unity can compress them down into less than 200KB in GPU memory using crunch compression (a variant of DXT5 algorithm). So yes, it's lossy, but for really high resolution stuff it doesn't make that much of a difference in quality, but the memory size is significantly lower.

Having that feature could attract more professional artists to C3 if they know they don't need to sacrifice their vision to fit memory constraints.

https://youtu.be/cqd1u_dfrkc?t=545

quick question, why are you trying to use DXT instead of just using a background image?

DXT is usually used for clouds/patterns stuff that you repeat as in webgl/opengl to create little things that look "big" they are not meant to replace the usage of jpeg,pngs textures.

while unity can compress the hell out of them, you can use png compression on your exported spritesheet once exported like tinypng etc... just make sure the size of the spritesheet doesn't change, you can bring down a 5mb to 100kb or less if done right.

also from what it sounds, loading the gpu memory by 200kb always doesn't seem a good approach, as images rendered in construct they render once, and then they just sit there they never get checked again by the gpu, unless you move them, that making it actually saving more memory than using, the only difference is with a preloaded texture image, you will have a loading wait for the 1st time on the start of game, other than that everything should be fast enough to be handled on a 2013 phone. anything older than that as a device (memory wise as an example take a A3 samsung galaxy 2013, if it runs on one of those will run on anything) is not worth optimizing for.

also so you can see what happens when you draw complex images in shaders take a look at shadertoy, my gpu cracks down every 2 demos i click (cause the gpu memory gets hogged down, and never clears unless im hard refreshing the cache there is tons of issues with that approach, since every pixel is drawn over and over again by your gpu shaders instead of just render in screen and check position/color change)... cause they are not meant to be used like that unless you run a workstation for that purpose.

having a 18mb 4k resolution background image sure is cool if you run it on a 4k monitor and im not talking about the 1920x1080 monitors that claim to be 4k... but an actual 4k monitor... that is 160cm wide or larger (also if you don't have a 4k gpu card, and a monitor/tv to be able to run 4k the detailing is pointless to have), if you do your game for majority of players a 1080p texture should be sharp enough to offer the quality and the detail needed. Mobile wise, you don't need textures greater than 480p.

in short if you want to use DXT1 = bmp images or flat lossless jpg

DXT3 accurate pixel drawing but no alpha good for patterns flat jpeg/bmp no transparency

DXT5 inaccurate pixeling for clouds and stuff that are blurry in background and don't require much sharpness = somehow a better compressed png.

difference in compression is about 50-1200kb depending on the compression you use on the png textures, memory usage while rendering images it will be insane huge as DXT always redraws the pixels, think of it as GPU idle usage around 10-20% still images and above if you move them (depending on device % - mobiles probably unplayable ).

and sure DXT is mostly used in 3d games, but if you are trying to do a 3d game in C3/C2 is probably not the best tool for that, you can do it, but you will probably have to import everything from a external source and just export with C3 but that will make C3 just a wrapper to export your game and not the engine you made the game in.

sorry if i sound a douche lol... i just don't get the convoluted way of doing a simple replica of the game you mentioned. it looks 2d to me, no need for 3d stuff, but just the illusion of 3d, the player won't care that much if your gameplay is great.

quick question, why are you trying to use DXT instead of just using a background image?

Because a sprite or tiled background is not compressed on the GPU. So a single 4K texture would take up like 90MB. This only makes sense for high resolution games where all the backgrounds are unique from screen to screen or level to level. Which means no repeated elements. I.e. you create an entire level background in a single photoshop project and export the layers as is. So tiled backgrounds and tilemaps are out of the question.

while unity can compress the hell out of them, you can use png compression on your exported spritesheet once exported like tinypng etc... just make sure the size of the spritesheet doesn't change, you can bring down a 5mb to 100kb or less if done right.

I'm not talking about compression on disk. Yes png files are great for low disk size. I'm talking about the texture being compressed on the GPU so the memory size at runetime is lower.

having a 18mb 4k resolution background image sure is cool if you run it on a 4k monitor and im not talking about the 1920x1080 monitors that claim to be 4k... but an actual 4k monitor... that is 160cm wide or larger (also if you don't have a 4k gpu card, and a monitor/tv to be able to run 4k the detailing is pointless to have), if you do your game for majority of players a 1080p texture should be sharp enough to offer the quality and the detail needed. Mobile wise, you don't need textures greater than 480p.

I'm not talking about screen resolution. I'm talking about the size of the texture. If your screen resolution is 1920x1080 and a level background is 4096px wide, then you would obviously have to scroll the screen to see it all.

i just don't get the convoluted way of doing a simple replica of the game you mentioned. it looks 2d to me, no need for 3d stuff, but just the illusion of 3d, the player won't care that much if your gameplay is great.

Also I'm not talking about making a 3d game. DXT has nothing to do with 3D games. Sure it was developed around the time 3D games got super popular so artists could continue pushing the limits. But DXT is simply a compression algorithm. It can compress a 4x4px texture or a 8192x8192px texture. The point is that the GPU can efficiently unpack them at runtime, regardless of 2D or 3D game.

Because a sprite or tiled background is not compressed on the GPU. So a single 4K texture would take up like 90MB. This only makes sense for high resolution games where all the backgrounds are unique from screen to screen or level to level. Which means no repeated elements. I.e. you create an entire level background in a single photoshop project and export the layers as is. So tiled backgrounds and tilemaps are out of the question.

i see, you could do it in C3 by using the webgl/opengl library directly (trough lots of effects or plugins) but then again wouldn't that be like taking a 80kb image and convert it to a base64 image? which actually will be worst size wise?

Edited: nevermind i just read your edit, seems cool, makes more sense after i read the article you sent also, interesting... however this type of implementation probably will affect C3 rendering way as is now in a major way and will need to much stuff to be changed, so slim chances to be implemented. I would vote it if you put it in the ideas bin for C3 forgot where is the link.

Edited2:

Because a sprite or tiled background is not compressed on the GPU. So a single 4K texture would take up like 90MB....

im sorry but that again isn't it disk space not gpu space... the gpu memory used will actually be less after load, no?

sure you will have a loading bar that loads 5x 90mb of files and you wait 5 seconds or 10 depending on device, but then at runtime the gpu usage will not redownload the 90mb again, will use the existing data and actually less memory than the shader usage.