Ah well, as long as there's an explanation... you seem to know what you're talking about. Really no need to talk down to me, as I admitted I had no idea at all about this sort of thing.
Now, given that I'm inept here, maybe you could humor me. Wouldn't I be using the very same compression in all three of the above cases (zip compressed, 7zip compressed, zip uncompressed)? I mean, regardless of the inital compression I'm using, no matter what I'm compressing all of the above as a zip in ultra mode for the distribution package, and when I use sdz STORE data files, it comes out smaller. That's all I know.
In case you were referring to the compression of the SDZs as being solid, I just did a couple of very, very basic tests - extracting some random files to see how long it'd take. It was instantaneous... wouldn't that mean it was non-solid? And regardless of whether I was using the "store" setting or the "normal" setting when compressing the sdz files, presumably it would be solid in both cases or non-solid in both cases, since I haven't even got the option to choose in the program I'm using.
Spring *appears* to load faster than ever now. Might easily be a placebo effect. Again, really, I'm clueless, I'm without a clue and there's no need to make fun.
SD7 vs SDZ: read time
Moderator: Moderators
Solid compression basically means that instead of compressing each small file separately, you first combine all the small files into one big file without compression, and then compress it. This is commonly done with tar on unix, or you can do it as you did by zipping twice. 7zip and other archivers such as rar can do this automatically as well. For archives with lots of small files you usually get much better results. But for things such as maps it is most likely negligable.
It would be possible to get spring to use solid 7zip archives since the new 7zip code doesn't crash with them. :) The downside is of course that it requires more memory to get useful speeds.
I did a quick test with the contents of the AASpring141.sd7 file, and recompressed it with ultra compression, with and without making it a solid archive. These are the results:
Normal: 9,05mb 130mb
Solid: 6,94mb 110mb
The second figure is how much memory spring was using after loading. It is probably possible to tweak the cache sizes that 7zip uses to improve this though.. (Note that the current spring version will not work well with solid archives since this caching is not enabled).
It would be possible to get spring to use solid 7zip archives since the new 7zip code doesn't crash with them. :) The downside is of course that it requires more memory to get useful speeds.
I did a quick test with the contents of the AASpring141.sd7 file, and recompressed it with ultra compression, with and without making it a solid archive. These are the results:
Normal: 9,05mb 130mb
Solid: 6,94mb 110mb
The second figure is how much memory spring was using after loading. It is probably possible to tweak the cache sizes that 7zip uses to improve this though.. (Note that the current spring version will not work well with solid archives since this caching is not enabled).
Basically its like Fnordia said, cadyr.
What you did is not the "real" solid compression (because 7zip reorders files, for example, in the way it thinks best suited for compression), but it comes to the same result.
I just missed something when writing my last post. I didnt catch that you just use the non-compression sdz file for the game...
As a good example why solid compression makes thinks better, think of 2 unitspics: lets say aircraft in front of the same cloudscape.
In a sdz, or a non-solid sd7, each is compressed by itself, as good as possible.
But if you put them non-compressed into a zip file, 7zip finds a file with 2datablocks inside, which both have very similar areas and thus can really compressed together. This is even true for already compressed files like pcx or jpg, as even the compressed representation may look very similar in both. Also file-headers & co are very similar and thus compressable (which may make a difference if its lot of very small files).
http://www.arturocampos.com/abstracts.html is a good starting point if you are interested in more information, but i warn you, this file compression stuff is a whole field of science by itself, and the tricks used in the best compressors border on the insane (like using neural nets for text prediction and co)
What you did is not the "real" solid compression (because 7zip reorders files, for example, in the way it thinks best suited for compression), but it comes to the same result.
I just missed something when writing my last post. I didnt catch that you just use the non-compression sdz file for the game...
As a good example why solid compression makes thinks better, think of 2 unitspics: lets say aircraft in front of the same cloudscape.
In a sdz, or a non-solid sd7, each is compressed by itself, as good as possible.
But if you put them non-compressed into a zip file, 7zip finds a file with 2datablocks inside, which both have very similar areas and thus can really compressed together. This is even true for already compressed files like pcx or jpg, as even the compressed representation may look very similar in both. Also file-headers & co are very similar and thus compressable (which may make a difference if its lot of very small files).
http://www.arturocampos.com/abstracts.html is a good starting point if you are interested in more information, but i warn you, this file compression stuff is a whole field of science by itself, and the tricks used in the best compressors border on the insane (like using neural nets for text prediction and co)