Hey there, just got another idea for reducing download filesize... found this program called PECompact2.
It reduces Spring.exe to 747 KB from 2.65 MB, and TASClient to 1.2 MB from 3.75 MB.
This only works for EXE files. It works by removing blank spaces and stuff like that, from what little I understand. I have tested the resulting EXEs and found them to work identically to the originals. There is no increase in startup time for any modern (1ghz+) computer.
Maybe reduce the download filesize by 1 MB or so? Try it and see.
Hope this helps!
Reduce download size some more? read
Moderator: Moderators
Reduce download size some more? read
Last edited by Caydr on 12 Aug 2006, 03:51, edited 2 times in total.
A file compressor (such as .zip ot .rar) cannot come even close to the compression factor of a exe compression program.AF wrote:This would affect the filesize of an install yes but not of an installer. It would be as useful as zipping up a zip archive.
But when you think about the modern internet connections speed the benefit of saving perhaps one meg in the installer by compressing all exe files is not worth the extra work and marginally higher loading times.
There is a executable compressor called crinkler, used to compress 4k demos. It would be dramatically more efficient than the tool mentioned in this thread, but downside would be that it would require several minutes of decompression everytime the exe is run :)
Where did you get that idea?
Normally, compression of exe-shrinkers is worse, just because the decode-stub has to be included in the exe.
Just as a quick example: 7zip compresses spring.exe to 720 kbyte and tasclient to 1240.
Compare to first post and explain how exe compressors are that much better (hint: rar,ace,7zip and anything decent reckognizes exe files, too , if they see one)
Normally, compression of exe-shrinkers is worse, just because the decode-stub has to be included in the exe.
Just as a quick example: 7zip compresses spring.exe to 720 kbyte and tasclient to 1240.
Compare to first post and explain how exe compressors are that much better (hint: rar,ace,7zip and anything decent reckognizes exe files, too , if they see one)
Probably because indeed you can't really use the same algorithms on .exes because they have a much different structure from many other types of files. Optimizing a single compression algorithm for executables means that this algo probably gets quite bad at "normal" data and the other way round.
It is easy however to select compression algorithm on the fly (based on e.g. file extension) and to use a compressor optimized for exes on .exe files, and a generic compressor on all other files.
It is easy however to select compression algorithm on the fly (based on e.g. file extension) and to use a compressor optimized for exes on .exe files, and a generic compressor on all other files.
Still the overhead of comrpessing and decompressing so you can get rid of filesize is a bit pointless considering the compressions i only wanted for the installer size.
Any benefits in doing this rather than using the compression with the installer is negligible. Why bother trying to shave 2-3 hundred kb off of a 20-30MB installer?
Any benefits in doing this rather than using the compression with the installer is negligible. Why bother trying to shave 2-3 hundred kb off of a 20-30MB installer?
Because if you want to save up disk size, then optimise your maps. There you can save dozen of megs per map, hundreds and hundreds of megs if you have many maps. Saving 2 meg on the exe is ridiculously negligible next to it.
Also, compressing the exe would make Spring load slower, since it'd have to decompress the exe in memory at each launch. To the contrary, saving on map tilesets would make make them load faster.
Also, compressing the exe would make Spring load slower, since it'd have to decompress the exe in memory at each launch. To the contrary, saving on map tilesets would make make them load faster.
zwzsg wrote: Also, compressing the exe would make Spring load slower, since it'd have to decompress the exe in memory at each launch.
Caydr wrote:I have tested the resulting EXEs and found them to work identically to the originals. There is no increase in startup time for any modern (1ghz+) computer.
LOrDo wrote:zwzsg wrote: Also, compressing the exe would make Spring load slower, since it'd have to decompress the exe in memory at each launch.Caydr wrote:I have tested the resulting EXEs and found them to work identically to the originals. There is no increase in startup time for any modern (1ghz+) computer.
zwzsg wrote:Because if you want to save up disk size, then optimise your maps. There you can save dozen of megs per map, hundreds and hundreds of megs if you have many maps. Saving 2 meg on the exe is ridiculously negligible next to it.
The increased initial program loading time is not noticable, even on my 1.6 ghz laptop. 1.6ghz is about the lowest anyone would want to go if they plan on running Spring, am I right? I don't think I've ever seen anyone in the lobby with a computer slower than 1.5, 1.6, 1.8... somewhere in there.
I think that if a map is a final version, has been tested to have no design flaws, why not go for broke and eliminate the ugly compression artifacts? It'll be the last time you have to download it, so why not make it memorable? AD is 25 megabytes, but you downloaded it 1 time. Certain other maps are 10 megabytes but are now up to _v5 or something by now. Anyway, this isn't about maps. I want to try to get the Spring package as tightly packed as possible, and a reduction of 1-2 mb off the installer size sounds like a step in that direction. I'm just asking that someone try it and see if there's a reduction like that when compared to an installer with uncompressed EXEs.
Already Spring is very impressively sized, in fact this is one of the things I most often see remarked upon. People say, my TA directory with all data files is 600 MB. Spring is... 30... yet is exponentially more advanced?
Whatever. It doesn't really matter, I guess. I just take it upon myself to post things like this, little ways to improve X or reduce filesize by Y with minimal or no work required. For instance, I posted about how about 700 KB worth of loading pictures weren't used in any way by any function of the game, they were even overwritten by XTA. I also have been finding more and more ways to shrink AA as well as improve compression techniques.
In the end, does 1 mb really matter? No, not really. But is the package as a whole cast in a better light by appearing to be more efficient and, to the layman, well designed? Yes.
I could've left AA at 18 megabytes, but I decided to cut out unnecessary stuff, find things that were overwritten or ignored by default, delete unused sounds, find ways to make the stuff compress better, and eventually bit by bit, it's now 10 megabytes smaller. More appealing to the end-user and less of an inconvenience to update. I think that this is one of the reasons AA is as popular as it is - it's very small and convenient. There isn't a kilobyte of bloat in the entire package now, but there is a little fat to cut from Spring still, and if you can, why not?
I think that if a map is a final version, has been tested to have no design flaws, why not go for broke and eliminate the ugly compression artifacts? It'll be the last time you have to download it, so why not make it memorable? AD is 25 megabytes, but you downloaded it 1 time. Certain other maps are 10 megabytes but are now up to _v5 or something by now. Anyway, this isn't about maps. I want to try to get the Spring package as tightly packed as possible, and a reduction of 1-2 mb off the installer size sounds like a step in that direction. I'm just asking that someone try it and see if there's a reduction like that when compared to an installer with uncompressed EXEs.
Already Spring is very impressively sized, in fact this is one of the things I most often see remarked upon. People say, my TA directory with all data files is 600 MB. Spring is... 30... yet is exponentially more advanced?
Whatever. It doesn't really matter, I guess. I just take it upon myself to post things like this, little ways to improve X or reduce filesize by Y with minimal or no work required. For instance, I posted about how about 700 KB worth of loading pictures weren't used in any way by any function of the game, they were even overwritten by XTA. I also have been finding more and more ways to shrink AA as well as improve compression techniques.
In the end, does 1 mb really matter? No, not really. But is the package as a whole cast in a better light by appearing to be more efficient and, to the layman, well designed? Yes.
I could've left AA at 18 megabytes, but I decided to cut out unnecessary stuff, find things that were overwritten or ignored by default, delete unused sounds, find ways to make the stuff compress better, and eventually bit by bit, it's now 10 megabytes smaller. More appealing to the end-user and less of an inconvenience to update. I think that this is one of the reasons AA is as popular as it is - it's very small and convenient. There isn't a kilobyte of bloat in the entire package now, but there is a little fat to cut from Spring still, and if you can, why not?
-
hollowsoul
- Posts: 665
- Joined: 06 Jun 2006, 19:49
Pro
U save download == 1 new map format (maybe 2 for arguement sake) i.e around 4 mb shaved off.
Con
Slightly increased loading times
Spring releasers (/team ??) will got to double check program doesnt mess up i.e might encounter bug.
My point of view is
After u download spring u talking about been able to download 1-2 extra maps. Slightly increased loading times & releasers will have to double check the compressed version of spring == the same i.e no bugs.
IMO not worth the hassle, and very few peep gonna notice the difference.
edit:- Nice find though
U save download == 1 new map format (maybe 2 for arguement sake) i.e around 4 mb shaved off.
Con
Slightly increased loading times
Spring releasers (/team ??) will got to double check program doesnt mess up i.e might encounter bug.
My point of view is
After u download spring u talking about been able to download 1-2 extra maps. Slightly increased loading times & releasers will have to double check the compressed version of spring == the same i.e no bugs.
IMO not worth the hassle, and very few peep gonna notice the difference.
edit:- Nice find though