Pages: [1]
  Print  
Author Topic: Using LZMA compression algorithm  (Read 24349 times)
Falkland
Member


Cakes 6
Posts: 590


« on: June 08, 2010, 10:14:08 AM »

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/
Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #1 on: June 08, 2010, 10:21:56 AM »

- It's supported by all the linux distributions and by the most popular windows programs ( WinZip and WinRAR )
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...
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Falkland
Member


Cakes 6
Posts: 590


« Reply #2 on: June 08, 2010, 10:23:12 AM »

- It's supported by all the linux distributions and by the most popular windows programs ( WinZip and WinRAR )
Also by whe Windows built-in "compressed folders" feature?

No , the windows compressed folders feature supports only zip compression
Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #3 on: June 08, 2010, 10:24:56 AM »

- It's supported by all the linux distributions and by the most popular windows programs ( WinZip and WinRAR )
Also by whe Windows built-in "compressed folders" feature?
No , the windows compressed folders feature supports only zip compression
So I suggest to continue using the standard zip format... "keep it simple"... Smiley
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
RMF
Member


Cakes 12
Posts: 694



« Reply #4 on: June 08, 2010, 11:47:08 AM »

@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.
Logged
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #5 on: June 08, 2010, 12:33:13 PM »

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.
Logged

Todo: Walk the cat.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #6 on: June 08, 2010, 01:38:26 PM »

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

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

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #7 on: June 08, 2010, 02:39:47 PM »

@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.

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.

Falkland doesn't suggest to use LZMA for .pk3s, but for the whole archive of the game.
which would bring no benefit since the game is compressed anyway.
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).
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
dbX
Member


Cakes 11
Posts: 199

Shazpaca!


WWW
« Reply #8 on: June 09, 2010, 06:15:40 AM »

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.
Logged

In defeat we learn.
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #9 on: June 09, 2010, 06:22:37 AM »

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 Tongue
Logged

Todo: Walk the cat.
Falkland
Member


Cakes 6
Posts: 590


« Reply #10 on: June 09, 2010, 08:48:21 AM »

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 Tongue

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 )
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #11 on: June 09, 2010, 12:11:30 PM »

Yeah , adding support for LZMA ( through liblzma or liblz ) should add also more speed in game loading if LZMA is used for archive compression
Actually it would lead to very long loading times.
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #12 on: June 09, 2010, 12:57:54 PM »

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.
Logged

Todo: Walk the cat.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #13 on: June 09, 2010, 02:21:23 PM »

These benchmarks are very different from the link in the first post (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...
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Cacatoes
Banned for leasing own account
Posts a lot
*

Cakes 73
Posts: 1427


also banned for baiting another to violate rules


« Reply #14 on: June 09, 2010, 04:20:44 PM »

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

Todo: Walk the cat.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #15 on: June 09, 2010, 04:48:00 PM »

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.
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Falkland
Member


Cakes 6
Posts: 590


« Reply #16 on: June 09, 2010, 05:03:29 PM »

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.

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.
« Last Edit: August 14, 2010, 11:06:32 AM by Falkland » Logged
Falkland
Member


Cakes 6
Posts: 590


« Reply #17 on: June 09, 2010, 05:11:00 PM »

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

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
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #18 on: June 09, 2010, 05:24:39 PM »

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
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Pages: [1]
  Print  
 
Jump to: