texture compression

[XH_JSMX]

Random Suggestion

Unless theres some weird reason not to, i don't see a reason why you shouldnt at least consider compressing a majority of the game textures to rgba 256 color PNG's maybe even 128 color to lower the size of the game overall, i did it out of boredom testing how small i could get the game, i compressed all ~34000 of the textures (on v18 stable, which totally did not take over 8hrs) & managed to decrease the games size from 4.6gb to 1.7gb with unnoticable loss to any image quality due to a majority of the games individual textures not having a very wide color range.

Here's a texture example to look at:

http://www.mediafire.com/?3ml5ox5h0h0f363

I used this image in example:

xenonauts\assets\units\xenonaut\armour.buzzard\weapon.lasercarbine\burstshoot_sw.png

Sizes

Original Image: 2.53 MB (2,660,276 bytes)

rgba 256 color: 731 KB (749,081 bytes) (virtually lossless)

rgba 128 color: 583 KB (597,218 bytes)*

*(little loss, only noticeable if you zoom in alot on the texture itself, in game the difference is visually irrelevant and unnoticeable)

In game testing screenshots (not of that texture in particular):

http://www.mediafire.com/folder/scenemn8st84d10,5u93jsq5b9s2ryv/shared

The first screenshot (1.png) is all original textures, and the second is using all 128 color textures on everything.

Anyways at the least a much smaller game, itd be almost lossless at 256 color & likely around 2-2.4gb in size, i like to save as much space as i can on my computer, and depending on how the game loads and renders the textures it may actually speed up loading with the much smaller files.

[maackey]

The game is still in development.

Until it is released, it doesn't make much sense to compress everything, as to make necessary changes you'd need to uncompress, edit the file, recompress, rinse and repeat. That is a lot of overhead time wasted to save a couple GBs of space. Storage is cheap, and unless you have fairly old, crappy internet, 4-5 GB isn't very taxing either. Its not like you have to download the whole game each time updates are released either... only differential changes are downloaded.

Besides, there are better ways to save size with compression & optimization. I'm not too keen on the specifics but .dds and other file formats which can be natively used by GPUs are much better for performance. Compressed pngs would have to be uncompressed somewhere along the line, which slows down the game -- I'd rather have a larger game that runs faster than a smaller one which takes longer to load, but thats just me.

[Chris]

It won't speed up the loading in the game because the engine doesn't support compressed textures (don't ask, long story) but it might work for the sprites.

We'll look into it, as it does seem a sensible step to take if we don't lose any image quality by doing so (the tiles are where most of the colour comes from on maps).

[Chris]

What tool did you use to reduce them to 256 colours, btw?

[XH_JSMX]

> maackey :

Overall i meant to only do it in the final stages of development. DDS would likely be larger than 256 color pngs (im pretty sure theres 256 color 8 bit dds too though) & yeah dds would load faster in game, but seeing as the game already supports png's i assumed itd take some development time to switch over to dds if it would be quick to develop then they should go with dds. 24 bit PNGs (what it has now) although lossless still use the exact same form of compression (zlib) and 256 color ones would take either the same or less time to uncompress into video memory than the pngs they have now so when the games getting finalized out of beta if still using the same pngs there no reason not to do it then.

> Chris :

I used some custom batch scripts i wrote and and the multithread version of PNGquant http://pngquant.org/ along with a slightly modded version of their 'PNGoo' GUI.

Edited September 17, 2013 by XH_JSMX

[Chris]

Thanks. I had a browse on the net and we found a tool to do it yesterday (Photoshop had problems with the alpha channel), and we're running some tests now.

So far it seems to have no gameplay effect whatsoever, but does significantly reduce the game size. Unless we find any serious issues we'll update all the images for the next build, which should reduce the game size down below 2gb as we're getting a 60-75% file size reduction and the unit sprites take up over 3gb of the 4.5gb game.

That should make things a lot less painful for people without fast connections - so thanks for suggesting this, it's been really helpful.

[Gorlom]

YAY! Good work XH_JSMX!

[Queamin]

YAY! Good work XH_JSMX!

Agreed

[a333]

Kudos.

[GizmoGomez]

Attaboy! (Or girl, you never know).

[XH_JSMX]

In case you want to save a crapload of time converting heres the batch script i made & pngquant.

http://www.mediafire.com/download/6ujv84a8wzc9d7u/xenopngquant.zip

Just extract the pngquant exe's to where xenonauts.exe is and run 'xhxeno_multithread.cmd'

I made it to auto scan all subfolders from wherever its run at and run pngquant on all png files, i included both the multithreaded and single threaded versions because some people had issues with the multithreaded one according to their site but its 2-3x as fast as the single threaded version given u have 2+ cores.

Edit: Oh and ignore any 'errors' there's 2-3 'png' files that arent actually pngs that were in my games directory. And if your gonna use some other batch program you can still used the cmd script i made just open it in notepad and change "pngquant.exe --force --speed=1 --ext .png 256 --" to whatever command the program your using needs and itll run it on every png file .

Edited September 19, 2013 by XH_JSMX

[maackey]

Haha, well I'm glad I was wrong This is pretty cool.