[Scummvm-devel] ScummVM binary size comparison

Neil Millstone neil at millstone.demon.co.uk
Sat Nov 8 16:02:07 CET 2008

Max Horn wrote:
> Am 08.11.2008 um 00:23 schrieb Neil Millstone:
>> > Hi Max and Team,
> [...]
>> >
>> > So I used Max's handy command from an earlier post to find the biggest
>> > object files.  I'm compiling with my normal settings.  ARM instruction
>> > set mode (I'm sure thumb mode doesn't work with the current compiler),
> It would still be a good thing to determine where it doesn't work,  
> precisely, and to report this to upstream, to get it fixed. According  
> to Robin, the binary size goes down several hundred KB, which we'll  
> never be able to cut by optimizing our code manually.
I'm going to do this, but tracking these random crashes with no debugger 
takes a very long time.  Working out a minimal piece of code which 
replicates the error takes even longer.   I get the feeling that Tramboi 
or Robin would be better at this than me!

I think this is the wrong solution though.  I had a version of 0.9.1 
that can run The Dig and Full Throttle.  I only managed this by 
compiling with Thumb and turning optimistaions off.  If we need to use 
Thumb just to keep games working that worked a few months ago, there's 
going to be no chance of getting the binary down to the size it was then 
in order to run The Dig/Full Throttle.

And what do we do next time the binary grows?

> [...]
>> > So, any ideas on how this can be improved?
> Add
> resp. the equivalent -D options. Then recompile. That might help a  
> little bit.
That's already in there.
> Next, I noticed that the built-in theme takes up 35k alone (I think  
> the old one used a similar number, though). Specifically, gui/themes/ 
> default.inc is 38870 (of course, you have to subtract a couple  
> thousand bytes for quotation marks etc.).
> With a trivial trick I was able to save 4k in my binary: I opened gui/ 
> themes/default.inc, and replaced all occurrences of " = " by "=", and  
> likewise ", " by "," -- after removing several thousand spaces this  
> way, default.inc was down to 35888 bytes, and the binary size was  
> reduced by 4096 bytes for me.
> Since the DS only needs the 320x240 GUI layout, I stripped the high- 
> res layout (by removing "gui/themes/scummclassic/classic_layout.stx",  
> then running "python scummtheme.py default scummclassic". Then removed  
> the whitespaces. Result: default.inc at 20976 bytes. In my case, the  
> binary now was 16384 bytes smaller (on OS X, it'll always be a  
> multiple of 1024 for technical reasons.).
> Extending this idea, we could shrink the theme even more if we apply  
> some kind of compression. Using a perl script / preprocessor magic, we  
> could automatically replace lots of keywords on systems with low  
> memory (both in the XML file as well as in the theming code itself):  
> "foreground" -> "fore", "drawdata" -> "dd", "drawstep" -> "ds", etc..  
> In addition, we could store the data zlib compressed and decompress it  
> on the fly.
Unfortunately, zlib is not compiled in for the DS port.  So it would add 
50Kb or so to the binary size to include it.
> No matter what we do, XML by itself always is wasteful, and doesn't  
> compress *that* well... We could avoid this, if we developed a way to  
> just dump the whole theme into a binary file, without concern for  
> forward compatibility, and compiled that in. Then we could also omit  
> the XML parser, and save even more space. But I am not sure whether  
> that would be worth it...
TBH, I wouldn't have ever chosen to use XML on low spec devices.  Not 
just the DS, but also some of the other ports we have.

Tokenising this stuff into a binary format seems like a good solution 
though.  There's already a preprocessor script for this stuff, so it 
would be an extension to that.

> BTW, is you code including scummclassic.zip or scummmodern.zip? You  
> shouldn't need either, the built-in theme should suffice.
Nope, neither are included.
> Oh, and do we really need super-expressive internal names for widgets  
> and dialogs? "GameOptions_Volume.EnableTabCheckbox" and similar  
> strings really add up to a lot.
> Anyway, there is still a lot more stuff that grew, and we need to look  
> into this.
I'm sure we'll find it!

- Neil

More information about the Scummvm-devel mailing list