OpenArena Message Boards

Why not using LZMA algorithm to distribuite the game ?

It has some advantages for the final user :
- It's more efficient ( the final archive will have a lower size than zip archive ) 
- It's faster on decompression
- It's supported by all the linux distributions and by the most popular windows programs ( WinZip and WinRAR )

On the other side it requires more time while compressing archives

http://multimedia.cx/eggs/bzip2-vs-lzma/

Also by whe Windows built-in "compressed folders" feature?
And there are many more compression programs other than WinZip & Winrar, and some of them are completely free. Anyway, various programs supports more formats than WinZip itself, so probably also LZMA...

No , the windows compressed folders feature supports only zip compression

So I suggest to continue using the standard zip format... "keep it simple"... :)

@gig, what newb knows what pk3s are (zips), can change anything he likes then, repacks and changes the name back to pk3, and expects it to magicly work? If you're gonna do that anyway you can also download another program to pack the stuff.

Falkland doesn't suggest to use LZMA for .pk3s, but for the whole archive of the game.

I'd say we can give both archives, that's what you usually do when you want to make some transition.
fromhell could upload the .7z, then we could build the .zip from it.

which would bring no benefit since the game is compressed anyway.

We were not talking about re-packaging single pk3s, but the download format of the whole installation package...
By the way, changing the pk3 compression format could make confusion: same extension, different compression? Different extension? I think standard zip is enough.

The benefit would be a smaller download file (I don't know how much, but I believe not too much, since pk3s are already compressed -probably the same thing you said-) for the downloader. I presume difficult gain something more than 10%, probably less. But if one does not have ADSL, he will not download the game anyway. So I believe following a "classic" standard would be better than a 10% smaller download file (a file you may delete after use).

I compressed my openarena folder into a .7z archive. I gained about 16 MB which is about 4% decrease in size. Yeah, that is not much. A significant increase would only happen when the pk3's would be recompressed which then again is not practical as these would have to be recompressed to zip after download (a huge problem for newbs). I say stick to zip.

However, I would like to be given the option to download a 7z archive where the contents of pk3's would be put into separate directories (for each pk3). This way I can recompress the pk3's myself once I extract the contents from the 7z archive. This may seem impractical but it's a one time job when there is a release, and considering how often Open Arena is released it should not be a problem.

I've tried recompressing all the pk3's (including the 0.85 patch) and I got them reduced from 373 MB to 247 MB, which is 126 MB less. That's a noticeable difference.

That's interesting. Let's bug ioq3 so that they support it :P

Yeah , adding support for LZMA ( through liblzma or liblz ) should add also more speed in game loading if LZMA is used for archive compression ; of course that does not imply automatically removing zip support which should be mantained at least for compatibility reason.

And there's at least another improvement that could be reported to ioquake3 which is still using version 6b of libjpeg while there's already the version 8b : http://www.ijg.org/

At least we could ask them to support turbo-jpeg , an ASM/SIMD improved libjpeg version ( http://libjpeg-turbo.virtualgl.org/ , http://cetus.sakura.ne.jp/softlab/jpeg-x86simd/jpegsimd.html ) which should replace libjpeg in Fedora 14 ( http://fedoraproject.org/wiki/Features/libjpeg-turbo )

Actually it would lead to very long loading times.

Found some bench:

http://blog.terzza.com/linux-compression-comparison-gzip-vs-bzip2-vs-lzma-vs-zip-vs-compress/

LZMA is like 3 times slower than ZIP at uncompressing.

These benchmarks are very different from the link in the first post (http://multimedia.cx/eggs/bzip2-vs-lzma/) (that reported LZMA faster in decompression).
I suppose this may depend from various factors (my personal guess):
- Your kind of processor: take a Pentium 4, an Athlon XP, a Celeron, a Xeon, a Centrino Duo, a Sempron, etc.. at same "speed", some may be more efficient handling integer numbers, others handling floating point number, other using multimedia data, other in logical operations... so a machine could hadle a compression format in a faster way that another format.
- Your operating system
- Your compression/decompression software. Maybe decompressing the same standard ZIP file using 7-Zip, or using Winzip, or using ZipCentral (etc etc) may take very different times...

The comparison in the bench linked in first topic is between bzip2 and lzma, not between zip and lzma. :)

May I remind you of the minimum target spec of OpenArena is still a Pentium II machine?

LZMA would make those choke to death, and take another forever at initial extraction as well since LZMA is also a memory hog, and is even worse when virtual memory kicks in.

There's also this : http://tukaani.org/lzma/benchmarks.html

Anyway those comparisons have still sense for uniprocessor machines ( zip and gzip were developed for running only on those kind of machines ) , but the same kinds of tests could have very different results in multicore and/or threaded environment.

I am actually not promoting or forcing for higher specs ( at least SIMD machines , like P3 ) , but discussions like this one about upgrading the engine are active also on ioquake3.org and other projects that use ioquake3 engine ask for better support for modern hardware.

Check this for example : http://wiki.ioquake3.org/Modular_Rendering_System

MD5 players in q3? that's a pipe dream and the normals will be crapped. Not worth the trouble, and besides, MD5 just plain sucks these days. How are they going to get tags?

The only renderers we need are:

Software - skimp a ton on map rendering, vertex light, interpreted shaders, pentium mmx assembly nut required
D3D6 - for the '98 spec machines and laptops
OGL1.x - what we have now
OGL2 - same looks, but just pure vertex shaders on everything to offload ALMOST EVERYTHING off the CPU (Gf8+), and maybe some GLSL inline stuff