compression question,. and a env. shader demo.

jph_wacheski · Post by **jph_wacheski** » Tue Jan 06, 2009 6:07 pm

Here is another little demo,. it uses an environment shader, and some funky techniques to create some interesting visuals. imho. press space to cycle the 3 'modes'. the first on is the most interesting to me,. may become a background for some SHMUP,.

The questions are about the optimal ZGE external bitmap and sound compresion,. here I have imported a 512X512 photo that I indexed at 256 colors in the gimp, then saved as a gif,. the file was 197k I tried a jpeg as well that file was 73k however ZGE uses full size of for a bitmap right? come to 786k here ~512^2*32(?) Then the only compresion it gets is from krunchy, (if that is what is used) and similar for the sound,. .raw is raw so the loop is 438k in the file,. krunchy does a good job of reducing this all to a 280k .exe what I am wondering is if anyone knows what is the most efficent format to use before importing the files. otherwise I will just experiment, but if one of you alread has i can learn from you.

also the decompresion when opening the .exe happens right away,. not sure this is under our control, or just down to krunchy,. but if the file was much larger a progress bar of the decompresion would be a good idea as the appearence is as though the .exe had failed,. due to no actual feedback for good chunk of seconds. I actually ran it twice thinking so!

with the raw 'music' loop (this is basicly another experiment as is this whole thing),. one issue I ran into is that to loop the sample I just put as many seconds as I want,. perhaps to loop endlessly we could use -1 ?? this may require a SoundStop component,. ? I'll do some more hack-testing,. . cheers.

Post by **VilleK** » Tue Jan 06, 2009 6:59 pm

Real-life sampled data (photos and sampled audio) is a pain to compress with general loss-less algorithms that the exe-compressors use. The optimal way is to compress photos as jpg and audio as mp3, but then ZGE would need built in mp3/jpg decoders in the runtime engine which requires quite a lot of space. An option would be that the engine call functions in the OS but that would make ZGE more OS-specific. I've tried to keep the OS-dependencies to a minimum, I see no reason why a ZGE-exe would not work on Windows 95/98 for instance.

You are right in that both audio and bitmaps are stored in ZGE-files uncompressed. So it is fully dependent on the performance of the exe-compressor. The only generic advice I can give is to try to reduce colors even more and import as gif or bmp instead of jpg. For audio reduce the quality 8khz or less, disguise the quality loss by playing it back with filtering on.

Btw, the demo looks and sounds real nice!

jph_wacheski · Post by **jph_wacheski** » Tue Jan 06, 2009 7:08 pm

cool,.thnaks ville that is about what I thought,. I may try to develop my skills with procedural bitmap creation to include some more painterly type tecniques so I can create some 'scene' type stuff for enviro maps,. thereby forgoing the photos,. however I will likely do some form of photo based game soon as photography is something I do enjoy,. and I have loads of macro type shots lying around that I think make great backdrops,. as this one.

Am I correct in my assumption that it is kkrunchy that produces that longish pause on execution and therefor a 'decompression' bar is out of our hands?

Post by **VilleK** » Tue Jan 06, 2009 7:14 pm

Yes, I just came back here because I realized I forgot to answer that part of your question. The pause is the decompressor. To prove it try running a uncompressed exe, there should be no pause. The documentation for kkrunchy does not mention a feature for displaying a progress bar so let's hope that will appear in a later version. Meanwhile you can try compress with less agressive kkrunchy settings, or use upx which generally will decompress faster.

kattle87 · Post by **kattle87** » Tue Jan 06, 2009 7:41 pm

Man that's COOL

really nice work JPH! And i suggest you try with UPX since it is able to use a more "general" compression algorithm more suitable for bitmaps.

And yes, expect some tricks for procedural gen of bitmaps

I just created this yesterday evening

jph_wacheski · Post by **jph_wacheski** » Tue Jan 06, 2009 8:34 pm

very nice kattle,. I was just wundering about finding more ways to do self tileing textures,. brick walls are allways a good idea!
I would really like to see some way to tile noise,. not sure it could be done with the noise we have now,. well I for one have no idea how anyway,. that is one thing that other procedural texture gen. systems have over ZGE,. but I am sure its just a matter of time till some equations emerge. math can't hide forever,. its just logic right.

thanks for the tip,. i indeed will try UPX for my photo game,.