[Scummvm-devel] ScummVM 0.12.0: Release status -- 2008-07-13

[Max Horn]

> size:
>
> scumm.plg: 0 + 1708348 + 3052 = 1711400
> kyra.plg: 0 + 1096324 + 64701 = 1161025
> parallaction.plg: 0 + 323224 + 258060 = 581284
> gob.plg: 0 + 580344 + 8 = 580352
> cruise.plg: 0 + 162844 + 379380 = 542224
>

My results:

TOTAL	CODE	DATA
1372160	1269760	102400	plugins/scumm.plugin
1028096	933888	94208	plugins/kyra.plugin
565248	290816	274432	plugins/parallaction.plugin
520192	450560	69632	plugins/gob.plugin
507904	122880	385024	plugins/cruise.plugin
397312	356352	40960	plugins/saga.plugin
397312	327680	69632	plugins/agos.plugin
356352	270336	86016	plugins/agi.plugin
311296	217088	94208	plugins/tinsel.plugin [SPOILER ;]
[...]
258048	155648	102400	plugins/cine.plugin
----------------------
7.49M  = 6.12M + 1.37M  (total over all engines)

Parallaction already was "fixed" (thanks peres), but also cruise  
(380k), cine (100k) and others are using lots of data. Maybe we can  
reduce some of them, a bit at least. Sometimes it's data tables we  
can't do anything about, but often (e.g. in the case of Tinsel, Cruise  
& Cine), it's an artifact of not fully OOified engines, which use  
global vars instead of class members (=allocated on heap).

All in all, the BSS size is still not as important as the raw code  
size, but that doesn't mean we should needlessly waste it, right? ;)  
Some details:
Cruise:
in background.cpp:
   char hwPage[64000]; (~64k}
in gfxModule.cpp:
   uint8 page00[320 * 200]; (~64k}
   uint8 page10[320 * 200]; (~64k}
   char screen[320 * 200];  (~64k}

Cine:
in texte.cpp
   byte textTable[256][2][16 * 8]; (~64k}

(and maybe more).

All of these should be turned into class members, which will  
automatically solve the issue. Buddha is working on OOifying those  
engines, I think.




Cheers,
Max