ScummVM

Am 08.11.2008 um 16:02 schrieb Neil Millstone:

[...]

>>
>> 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!

Quite possible. If you can give them at least a hint where to look,  
that would already help. I guess once you know what code roughly  
breaks, you can try to figure out what in there miscompiles, and use  
that to construct a minimal example.


>
> 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?

If you read what I wrote, I specifically said that we should try to  
reduce code size actively -- but we will never be able to save 500KB.  
Thumbs mode will. Engine also grow, so, in my eyes it makes perfect  
sense to do both things to reduce code size: Comb the code, but also  
try to get thumbs mode working.



Bye,
Max

Hi there,

Just to give a small update on this: We are considering removing the  
XML parser altogether, and instead using an external tool to convert  
the theme XML (and later, the virtual keyboard XML) into a binary  
format, which would be a lot more compact than XML, and even could  
contain image data. Validation of the XML would be done externally,  
too (using DTD / XML Scheme / RelaxNG). This would probably cut  
50-100k from the current code size. The binary theme like would have  
to be regenerated for new releases.

My hope is that Tanoku is willing to work on this (I'd be happy to  
provide some assistance, too), but maybe others are also interested --  
if so, please talk to us :)

Bye,
Max

Hey all,

you are right Max, I'm willing to start working on the new theme
format asap, although there are a few things we should consider first.
Mainly, on which language should we write the theme parsing tool? I
was thinking about Python (again, nothing related with my zealotry),
just because it already comes with batteries i.e. good XML parsing
libraries. C++ is obviously also an option, but we would have to add
libXML as a dependency, which is not really cool.

Also, regarding the external validation, I only have experience with
DTD, but RelaxNG's syntax does look much cleaner. Should we stick with
the latter? There are also a couple other considerations regarding the
binary format itself, I'll discuss them later.

Does anybody else have any insightful input?

Cheers,

Vicent Martí
----------------
http://www.smartlikearoboc.com



On Wed, Nov 12, 2008 at 11:00 AM, Max Horn <max@...> wrote:
> Hi there,
>
> Just to give a small update on this: We are considering removing the
> XML parser altogether, and instead using an external tool to convert
> the theme XML (and later, the virtual keyboard XML) into a binary
> format, which would be a lot more compact than XML, and even could
> contain image data. Validation of the XML would be done externally,
> too (using DTD / XML Scheme / RelaxNG). This would probably cut
> 50-100k from the current code size. The binary theme like would have
> to be regenerated for new releases.
>
> My hope is that Tanoku is willing to work on this (I'd be happy to
> provide some assistance, too), but maybe others are also interested --
> if so, please talk to us :)
>
> Bye,
> Max
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>

Am 12.11.2008 um 11:19 schrieb Vicent Marti:

> Hey all,
>
> you are right Max, I'm willing to start working on the new theme
> format asap, although there are a few things we should consider first.
> Mainly, on which language should we write the theme parsing tool? I
> was thinking about Python (again, nothing related with my zealotry),
> just because it already comes with batteries i.e. good XML parsing
> libraries. C++ is obviously also an option, but we would have to add
> libXML as a dependency, which is not really cool.

Python is perfectly fine by me.

>
>
> Also, regarding the external validation, I only have experience with
> DTD, but RelaxNG's syntax does look much cleaner. Should we stick with
> the latter?

If you can hack up a DTD quickly, do so. It's trivial to add a RelaxNG  
file or XML Schema later on, if we desire so. These two provide  
extended validations abilities, which I find attractive. But even a  
DTD should suffice to replicate most of our built-in validation, and  
more.


> There are also a couple other considerations regarding the
> binary format itself, I'll discuss them later.

Sure.

Bye,
Max

<html><body class="ApplePlainTextBody" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>Am 12.11.2008 um 11:19 schrieb Vicent Marti:<br><br><blockquote type="cite">Hey all,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">you are right Max, I'm willing to start working on the new theme<br></blockquote><blockquote type="cite">format asap, although there are a few things we should consider first.<br></blockquote><blockquote type="cite">Mainly, on which language should we write the theme parsing tool? I<br></blockquote><blockquote type="cite">was thinking about Python (again, nothing related with my zealotry),<br></blockquote><blockquote type="cite">just because it already comes with batteries i.e. good XML parsing<br></blockquote><blockquote type="cite">libraries. C++ is obviously also an option, but we would have to add<br></blockquote><blockquote type="cite">libXML as a dependency, which is not really cool.<br></blockquote><br>Python is perfectly fine by me.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Also, regarding the external validation, I only have experience with<br></blockquote><blockquote type="cite">DTD, but RelaxNG's syntax does look much cleaner. Should we stick with<br></blockquote><blockquote type="cite">the latter?<br></blockquote><br>If you can hack up a DTD quickly, do so. It's trivial to add a RelaxNG file or XML Schema later on, if we desire so. These two provide extended validations abilities, which I find attractive. But even a DTD should suffice to replicate most of our built-in validation, and more.<br><br><br><blockquote type="cite">There are also a couple other considerations regarding the<br></blockquote><blockquote type="cite">binary format itself, I'll discuss them later.<br></blockquote><br>Sure.<br><br>Bye,<br>Max<br><br><br></body></html>

Hi everybody,

Here are some mores idea how to save code size:

== Trim base/commandline.cpp ==

Virtuall all code in that file is not needed on the DS (or any other  
port without a console). AFAICT, the DS only needs the "-c" command  
line option, to choose different config files for the various builds  
with different engines en-/disabled.
Well, these days it shouldn't do that anyway -- just overload  
OSystem::openConfigFileForReading() to return the config file the  
specific build. According to Neil's figures, that could save about 24kb.

Short term, we could add some #ifdef magic to conditionally remove all  
that on those ports; on the long run, we could finally look into  
implementing the idea of a "class Main" replacing much of the code in  
base/main.cpp and base/commandline.cpp, see <http://wiki.scummvm.org/index.php/User:Fingolfin#Misc 
 >


== Disable useless debug() and printf() calls ==
On ports without a console, you usually just drop whatever output  
debug() or printf() are meant to produce (except maybe in debug  
builds, if you can transfer that data of a serial port.
But if one does so by replacing the body of those functions by  
nothing, the calls still remain in the code, and that costs a lot (as  
the message string then is included, too). We could solve this by  
introducing a new (set of) macro(s), like this:
#ifdef DISABLE_DEBUG_OUTPUT
#define SVM_DEBUG(x)	do {} while(0)
#else
#define SVM_DEBUG(x)	debug x
#endif

Then instead of
   debug(1, "foo");
we would write
   SVM_DEBUG((1, "foo"));
(notice the extra set of parentheses) to completely remove any trace  
of that call from the binary. I haven't measured how much this saves  
in total, but for a sample file (common/advancedetector.cpp), it was  
1063 raw bytes of code. Not much. But if we also cover printf and  
warning...


Bye,
Max

Max Horn wrote:
> Hi everybody,
> 
> Here are some mores idea how to save code size:

Another thing that could probably be trimmed is
engines/scumm/charset-fontdata.cpp. As far as I can tell, most
characters are identical in all charsets except, of course, Russian. The
difference would only be a few KB at most (each font is 1 KB), but I
suppose every little bit helps...

I've put together some images to help compare them:

http://www.update.uu.se/~d91tan/ScummVM/english.png
http://www.update.uu.se/~d91tan/ScummVM/french.png
http://www.update.uu.se/~d91tan/ScummVM/german0.png
http://www.update.uu.se/~d91tan/ScummVM/german2.png
http://www.update.uu.se/~d91tan/ScummVM/italian.png
http://www.update.uu.se/~d91tan/ScummVM/spanish.png

Mind you, I may have messed up in creating these images, so here is the
quickly hacked together program I used to dump the fonts to X PixMaps:

http://www.update.uu.se/~d91tan/ScummVM/makefont.cpp

Torbjörn

Quick update: There has been quite a bit of progress with the binary parser.

Is it ok if I work on the ScummVM SVN or should I use my own SVN
repository until the parser is stable/finished?

Vicent Martí
----------------
http://www.smartlikearoboc.com



On Wed, Nov 12, 2008 at 9:13 PM, Torbjörn Andersson
<eriktorbjorn@...> wrote:
> Max Horn wrote:
>> Hi everybody,
>>
>> Here are some mores idea how to save code size:
>
> Another thing that could probably be trimmed is
> engines/scumm/charset-fontdata.cpp. As far as I can tell, most
> characters are identical in all charsets except, of course, Russian. The
> difference would only be a few KB at most (each font is 1 KB), but I
> suppose every little bit helps...
>
> I've put together some images to help compare them:
>
> http://www.update.uu.se/~d91tan/ScummVM/english.png
> http://www.update.uu.se/~d91tan/ScummVM/french.png
> http://www.update.uu.se/~d91tan/ScummVM/german0.png
> http://www.update.uu.se/~d91tan/ScummVM/german2.png
> http://www.update.uu.se/~d91tan/ScummVM/italian.png
> http://www.update.uu.se/~d91tan/ScummVM/spanish.png
>
> Mind you, I may have messed up in creating these images, so here is the
> quickly hacked together program I used to dump the fonts to X PixMaps:
>
> http://www.update.uu.se/~d91tan/ScummVM/makefont.cpp
>
> Torbjörn
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>

Max Horn wrote:
> Hi everybody,
>
> Here are some mores idea how to save code size:
>
> == Trim base/commandline.cpp ==
>
> Virtuall all code in that file is not needed on the DS (or any other 
> port without a console). AFAICT, the DS only needs the "-c" command 
> line option, to choose different config files for the various builds 
> with different engines en-/disabled.
> Well, these days it shouldn't do that anyway -- just overload 
> OSystem::openConfigFileForReading() to return the config file the 
> specific build. According to Neil's figures, that could save about 24kb.
>
> Short term, we could add some #ifdef magic to conditionally remove all 
> that on those ports; on the long run, we could finally look into 
> implementing the idea of a "class Main" replacing much of the code in 
> base/main.cpp and base/commandline.cpp, see 
> <http://wiki.scummvm.org/index.php/User:Fingolfin#Misc>
#ifdef'ing that out sounds like a great idea.
>
>
> == Disable useless debug() and printf() calls ==
> On ports without a console, you usually just drop whatever output 
> debug() or printf() are meant to produce (except maybe in debug 
> builds, if you can transfer that data of a serial port.
> But if one does so by replacing the body of those functions by 
> nothing, the calls still remain in the code, and that costs a lot (as 
> the message string then is included, too). We could solve this by 
> introducing a new (set of) macro(s), like this:
> #ifdef DISABLE_DEBUG_OUTPUT
> #define SVM_DEBUG(x)    do {} while(0)
> #else
> #define SVM_DEBUG(x)    debug x
> #endif
>
> Then instead of
>   debug(1, "foo");
> we would write
>   SVM_DEBUG((1, "foo"));
> (notice the extra set of parentheses) to completely remove any trace 
> of that call from the binary. I haven't measured how much this saves 
> in total, but for a sample file (common/advancedetector.cpp), it was 
> 1063 raw bytes of code. Not much. But if we also cover printf and 
> warning...
>
That sounds like quite a lot.  1063 bytes per file would make a whole 
lot of bytes over the whole binary.  Sounds like something worth trying.

Thanks for your help,

- Neil

On 11/12/08, Max Horn <max@...> wrote:
> == Disable useless debug() and printf() calls ==
> On ports without a console, you usually just drop whatever output
> debug() or printf() are meant to produce (except maybe in debug
> builds, if you can transfer that data of a serial port.
> But if one does so by replacing the body of those functions by
> nothing, the calls still remain in the code, and that costs a lot (as
> the message string then is included, too). We could solve this by
> introducing a new (set of) macro(s), like this:
> #ifdef DISABLE_DEBUG_OUTPUT
> #define SVM_DEBUG(x)	do {} while(0)
> #else
> #define SVM_DEBUG(x)	debug x
> #endif

Another solution would be to replace the declaration

void debug(int level, char *message, ...); // or whatever it is

with

#ifdef HAVE_CONSOLE
void debug(int level, char *message, ...); // or whatever it is
#else
inline void debug(int level, char *message, ...) { }
#endif

I would be terrified to find an otherwise useful compiler that would
not optimize this out trivially. This implies that the code does
essentially the same thing, but it is a drop-in replacement; IMHO it
is also much more elegant.
-- 
Cheers
- Rafał

Am 12.11.2008 um 22:38 schrieb Vicent Marti:

> Quick update: There has been quite a bit of progress with the binary  
> parser.
>
> Is it ok if I work on the ScummVM SVN or should I use my own SVN
> repository until the parser is stable/finished?

Fine by me if you work on trunk, as long as the phases during which  
everything is completely unusable are not too long... :)

Oh, and leave out that HD formatting code, please ;).


Bye,
Max

Am 12.11.2008 um 13:48 schrieb Neil Millstone:

> Max Horn wrote:
[...]

>>
>> == Disable useless debug() and printf() calls ==
>>
[...]
>> I haven't measured how much this saves
>> in total, but for a sample file (common/advancedetector.cpp), it was
>> 1063 raw bytes of code. Not much. But if we also cover printf and
>> warning...
>>
> That sounds like quite a lot.  1063 bytes per file would make a whole
> lot of bytes over the whole binary.  Sounds like something worth  
> trying.

Well, common/advancedetector.cpp is not necessarily representative for  
all files; overall, the effect was lower than I hoped for. Still, a  
few kb on my intel mac.

Anyway, try adding a

  #define DISABLE_TEXT_CONSOLE

and recompile. And maybe post an updated list of the biggest *.o files  
you get with current SVN. And maybe with the theme.inc trick applied I  
described -- i.e. from the trunk dir, run:
   rm gui/themes/scummclassic/classic_layout.stx gui/themes/ 
scummmodern/scummmodern_layout.stx
   cd gui/themes
   python scummtheme.py default scummclassic
Optionally, you can finally run
   python scummtheme.py makeall
to recreate the .ZIP files, but I think you don't need them


I would perform a test compile myself, but I currently can't compile  
the DS port, it complains about these file missing: icons_raw.h and  
keyboard_raw.h.

Bye,
Max

P.S.:

Also try this in rev 35045 or newer:
#define DISABLE_COMMAND_LINE

Bye,
Max

In message <e4eb41060811122108w5f52e238w25aaa1247becead6@...>
          "Rafał Rzepecki" <divided.mind@...> wrote:
> Another solution would be to replace the declaration
> 
> void debug(int level, char *message, ...); // or whatever it is
> 
> with
> 
> #ifdef HAVE_CONSOLE
> void debug(int level, char *message, ...); // or whatever it is
> #else
> inline void debug(int level, char *message, ...) { }
> #endif
> 
> I would be terrified to find an otherwise useful compiler that
> would not optimize this out trivially. This implies that the code
> does essentially the same thing, but it is a drop-in replacement;
> IMHO it is also much more elegant.

IME, lots of compilers ignore "inline" declarations. You should
prepare yourself to be terrified on a regular basis if you ever have
to use a wide range of compilers :)

I'd vote for the macroised version.

Robin
-- 
Robin Watts,             Email: <mailto:Robin.Watts@...>
Warm Silence Software,   WWW:   <http://www.wss.co.uk/>
P.O.Box 28, Woodstock,   Tel:   01608 737172 (or Mobile: 07885 487642)
Oxfordshire, OX20 1XX    Fax:   01608 737172

On Thursday 13 November 2008 15:02:29 Robin Watts wrote:
> IME, lots of compilers ignore "inline" declarations. You should
> prepare yourself to be terrified on a regular basis if you ever have
> to use a wide range of compilers :)
>
> I'd vote for the macroised version.

I'm all for the "inline" version till we find out that a compiler we're 
using ignores "inline" in that case, since these macros would make the code 
a bit uncleaner IMHO.

// Johannes

Am 13.11.2008 um 15:02 schrieb Robin Watts:
[...]
>
>
> IME, lots of compilers ignore "inline" declarations. You should
> prepare yourself to be terrified on a regular basis if you ever have
> to use a wide range of compilers :)
>
> I'd vote for the macroised version.

Welll, I already implemented the "inline" version, at least GCC seems  
to honor it just fine (at least when building with -Os or any other  
non-zero optimization level). I would also expect MSVC to do so. As  
Johannes said, if we encounter a compiler which has troubles with  
this, we can still change it to the macro approach :)


Cheers,
Max

Max Horn wrote:
[...]
> Welll, I already implemented the "inline" version, at least GCC seems  
> to honor it just fine (at least when building with -Os or any other  
> non-zero optimization level). I would also expect MSVC to do so. As  
> Johannes said, if we encounter a compiler which has troubles with  
> this, we can still change it to the macro approach :)

Don't forget the new C/C++ vararg macro support; that'll provide a
syntax-compatible alternate implementation.

It also has the advantage that if faced with a really ancient compiler
that does neither empty inlines nor vararg macros, it should be
relatively straightforward to bolt on a third-party preprocessor and
make them work that way.

-- 
David Given
dg@...

Am 13.11.2008 um 18:08 schrieb David Given:

> Max Horn wrote:
> [...]
>> Welll, I already implemented the "inline" version, at least GCC seems
>> to honor it just fine (at least when building with -Os or any other
>> non-zero optimization level). I would also expect MSVC to do so. As
>> Johannes said, if we encounter a compiler which has troubles with
>> this, we can still change it to the macro approach :)
>
> Don't forget the new C/C++ vararg macro support; that'll provide a
> syntax-compatible alternate implementation.

> It also has the advantage that if faced with a really ancient compiler
> that does neither empty inlines nor vararg macros, it should be
> relatively straightforward to bolt on a third-party preprocessor and
> make them work that way.

I wouldn't consider it an acceptable solution to potentially force  
people who want to port ScummVM to "exotic" systems to "bolt on" a 3rd  
party preprocessor. It seems to have to more or less the same drawback  
as the "use inline function" approach (not supported by all  
compilers), only worse: No easy fallback (if the compiler doesn't  
implement / optimize inline properly, it still compilers), and I  
believe less compilers support varadic macros.


For now, let's just continue as-is, and if we find a port where the  
compiler does not optimize empty inline functions away properly, we  
can still reconsider. Really, folks, the code is already in  
Subversion, so, unless you know any system on which it causes  
troubles, let's put this to the rest, and let's focus on more  
important issues, e.g. the color of the bikeshed. *ggg*.

Bye,
Max

Hi guys,There is also a mixed approach by using the preprocessor... for the inline qualifier only :)MSVC:#define FORCE_INLINE __forceinline
G++:#define FORCE_INLINE __attribute__((always_inline))
--- En date de : Jeu 13.11.08, Max Horn <max@...> a écrit :
De: Max Horn <max@...>
Objet: Re: [Scummvm-devel] ScummVM binary size comparison
À: "David Given" <dg@...>
Cc: "ScummVM devel" <scummvm-devel@...>
Date: Jeudi 13 Novembre 2008, 19h01

Am 13.11.2008 um 18:08 schrieb David Given:

> Max Horn wrote:
> [...]
>> Welll, I already implemented the "inline" version, at least
GCC seems
>> to honor it just fine (at least when building with -Os or any other
>> non-zero optimization level). I would also expect MSVC to do so. As
>> Johannes said, if we encounter a compiler which has troubles with
>> this, we can still change it to the macro approach :)
>
> Don't forget the new C/C++ vararg macro support; that'll provide a
> syntax-compatible alternate implementation.

> It also has the advantage that if faced with a really ancient compiler
> that does neither empty inlines nor vararg macros, it should be
> relatively straightforward to bolt on a third-party preprocessor and
> make them work that way.

I wouldn't consider it an acceptable solution to potentially force  
people who want to port ScummVM to "exotic" systems to "bolt
on" a 3rd  
party preprocessor. It seems to have to more or less the same drawback  
as the "use inline function" approach (not supported by all  
compilers), only worse: No easy fallback (if the compiler doesn't  
implement / optimize inline properly, it still compilers), and I  
believe less compilers support varadic macros.


For now, let's just continue as-is, and if we find a port where the  
compiler does not optimize empty inline functions away properly, we  
can still reconsider. Really, folks, the code is already in  
Subversion, so, unless you know any system on which it causes  
troubles, let's put this to the rest, and let's focus on more  
important issues, e.g. the color of the bikeshed. *ggg*.

Bye,
Max

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scummvm-devel mailing list
Scummvm-devel@...
https://lists.sourceforge.net/lists/listinfo/scummvm-devel

I wrote:
> Another thing that could probably be trimmed is
> engines/scumm/charset-fontdata.cpp.

To demonstrate what I mean, I've submitted a patch:

https://sourceforge.net/tracker/index.php?func=detail&aid=2278665&group_id=37116&atid=418822

I have no idea whether or not it does any good, though.

Torbjörn Andersson

Hi everyone,

I applied the following fixes:
- Set the DISABLE_TEXT_CONSOLE and DISABLE_COMMAND_LINE defines.
- Rebuilt the theme to strip whitespace as suggested

With these, there is now 2028Kb of RAM in use at the launcher.  So we've 
trimmed 120Kb of fat, which is pretty good going!  Another 60Kb and 
we'll be were we were at 0.12.0 release time.

I haven't yet applied the font data fix.

The largest files in the DS port are now:

$ size */*.a |sort -nr |head -n 20
  37786       0       0   37786    939a ThemeParser.o (ex gui/libgui.a)
  37207       0       0   37207    9157 ThemeEngine.o (ex gui/libgui.a)
  26642       0       0   26642    6812 launcher.o (ex gui/libgui.a)
  21657      24       0   21681    54b1 options.o (ex gui/libgui.a)
  17219       0       0   17219    4343 VectorRendererSpec.o (ex 
graphics/libgraphics.a)
  16883       0       0   16883    41f3 audiostream.o (ex sound/libsound.a)
  16173       0       0   16173    3f2d about.o (ex gui/libgui.a)
  15006    1172    2048   18226    4732 adlib.o (ex sound/libsound.a)
  12868       0   33516   46384    b530 fmopl.o (ex sound/libsound.a)
  11929       4      68   12001    2ee1 config-manager.o (ex 
common/libcommon.a)
  11568       0       0   11568    2d30 saveload.o (ex gui/libgui.a)
  11473       0       0   11473    2cd1 advancedDetector.o (ex 
common/libcommon.a)
  11404       0    1024   12428    308c unarj.o (ex common/libcommon.a)
  10667       0       0   10667    29ab widget.o (ex gui/libgui.a)
  10411       0       0   10411    28ab console.o (ex gui/libgui.a)
  10374       0       0   10374    2886 default-events.o (ex 
backends/libbackends.a)
   9749       1      24    9774    262e ym2612.o (ex sound/libsound.a)
   9525       0       0    9525    2535 massadd.o (ex gui/libgui.a)
   9302       0       4    9306    245a archive.o (ex common/libcommon.a)
   8743       0       0    8743    2227 stream.o (ex common/libcommon.a)

I'm not sure why you can't build the code currently, Max.  The two 
header files you mentioned should be automatically built by the 
makefile.  This is something which hasn't changed since it was written.  
Perhaps deleting the whole scummvm-A folder and rebuilding would make it 
work?

Regards,

- Neil

Am 16.11.2008 um 04:17 schrieb Neil Millstone:

> Hi everyone,
>
> I applied the following fixes:
> - Set the DISABLE_TEXT_CONSOLE and DISABLE_COMMAND_LINE defines.
> - Rebuilt the theme to strip whitespace as suggested
>
> With these, there is now 2028Kb of RAM in use at the launcher.  So  
> we've
> trimmed 120Kb of fat, which is pretty good going!  Another 60Kb and
> we'll be were we were at 0.12.0 release time.

Great :)
>
>
> I haven't yet applied the font data fix.

That one is actually already in the repos. I also just commited a  
change to sound/audiostream.o which saves another 4k or so. And a  
change to sound/fmopl.cpp which saves 32k (by moving a static array to  
the heap).

Also, Tanoku / Vicent is working on shrinking ThemeParser &  
ThemeEngine. Once that is done, I am pretty sure we'll be at or even  
better than what we had in 0.12.0. Of course, no reason to stop  
there... ;)

All in all, I now get this (note that I sort by TEXT+DATA, which seems  
to be more meaningful here):

$ /opt/devkitpro/devkitARM/bin/arm-eabi-size arm9/scummvm-A/*/*.a |cut  
-c27- |sort -nr |head -n 20
36407	   8e37	ThemeParser.o (ex arm9/scummvm-A/gui/libgui.a)
35114	   892a	ThemeEngine.o (ex arm9/scummvm-A/gui/libgui.a)
25028	   61c4	launcher.o (ex arm9/scummvm-A/gui/libgui.a)
21290	   532a	options.o (ex arm9/scummvm-A/gui/libgui.a)
18244	   4744	adlib.o (ex arm9/scummvm-A/sound/libsound.a)
17152	   4300	VectorRendererSpec.o (ex arm9/scummvm-A/graphics/ 
libgraphics.a)
15684	   3d44	about.o (ex arm9/scummvm-A/gui/libgui.a)
15540	   3cb4	mixer.o (ex arm9/scummvm-A/sound/libsound.a)
15344	   3bf0	fmopl.o (ex arm9/scummvm-A/sound/libsound.a)
11376	   2c70	unarj.o (ex arm9/scummvm-A/common/libcommon.a)
11236	   2be4	audiostream.o (ex arm9/scummvm-A/sound/libsound.a)
10470	   28e6	saveload.o (ex arm9/scummvm-A/gui/libgui.a)
10204	   27dc	widget.o (ex arm9/scummvm-A/gui/libgui.a)
10204	   27dc	default-events.o (ex arm9/scummvm-A/backends/ 
libbackends.a)
10167	   27b7	config-manager.o (ex arm9/scummvm-A/common/libcommon.a)
10078	   275e	ym2612.o (ex arm9/scummvm-A/sound/libsound.a)
  9894	   26a6	console.o (ex arm9/scummvm-A/gui/libgui.a)
  9478	   2506	advancedDetector.o (ex arm9/scummvm-A/common/libcommon.a)
  8323	   2083	archive.o (ex arm9/scummvm-A/common/libcommon.a)
  8276	   2054	stream.o (ex arm9/scummvm-A/common/libcommon.a)

Interestingly, the numbers are smaller than on your system. I don't  
know why, I didn't do anything special to the settings in the  
Makefile, other than adding the same defines as you did. Maybe we have  
different versions of devkitPro? Mine is gcc version 4.3.0 (devkitARM  
release 23b), according to "/opt/devkitpro/devkitARM/bin/arm-eabi-c++ - 
v"

Oh, and I wonder why mixer.o occurs for me in the top 20, but not for  
you. Weird.



[..]
> I'm not sure why you can't build the code currently, Max.  The two
> header files you mentioned should be automatically built by the
> makefile.  This is something which hasn't changed since it was  
> written.
> Perhaps deleting the whole scummvm-A folder and rebuilding would  
> make it
> work?

Actually, that was what caused the problem in the first place. a "make  
clean" fixed it. The problem is a subtle bug in the Makefile: It does  
not declare how/where icons_raw.h is created, it just is created as a  
side-effect of build rule for arm9/data/icons.o -- but icons_raw.h was  
created as arm9/data/scummvm-A/icons_raw.h. Hence when I removed that  
dir, the header file was not regenerated.

I guess this should be fixed in the build file -- the header should be  
created in arm9/data/.

Bye,
Max

After the new binary format is ready, we'll be _way_ better than in
0.12, since it removes most of the bloat which I added during the SoC
(internal validation and so on), and you guys have been doing a great
work at saving up more space from other places of the code.

Cheers,

-- 
Vicent Martí

I was wondering... Since ScummVM is slowly accumulating a number of
different audio and video decoders, would it be useful if we
automatically disabled the ones that aren't used by the set of engines
being compiled?

Or are linkers clever enough to remove unused code automagically?

Torbjörn Andersson

On 2008-12-31 22:44:23 +0100, Torbjörn Andersson wrote:
> I was wondering... Since ScummVM is slowly accumulating a number of
> different audio and video decoders,

Indeo3 support, for example, adds 72kb through the three big correction
tables alone. Currently, it's still in the Gob namespace, though.