[Scummvm-devel] Memory consumption in GUI branch

Neil Millstone neil at millstone.demon.co.uk
Mon Nov 3 23:06:49 CET 2008


Robin Watts wrote:
> In message <91A8741B-9A08-4EFA-A795-0792C092579C at quendi.de>
>           Max Horn <max at quendi.de> wrote:
>   
>> Am 26.10.2008 um 05:08 schrieb Neil Millstone:
>>     
>>> Robin Watts wrote:
>>>       
>>>> In message <48F08B15.5020309 at millstone.demon.co.uk>
>>>>          Neil Millstone <neil at millstone.demon.co.uk> wrote:
>>>>         
>>>>> The code growth you mentioned does sound a little worrying, if
>>>>> the same is seen on the DS build (ARM code tends to have quite
>>>>> poor code density) then ScummVM is unlikely to run properly
>>>>> anymore, but as you said, only a single bit format is used for
>>>>> the GUI, so that should help.
>>>>>           
>>>> I've just rebuilt DS scummvm here, and the standard ARM build (a
>>>> cleanish trunk) comes out to 1627712 bytes. If I enable thumb
>>>> mode during the build (and tweak various ARM routines to cope
>>>> with being called in thumb mode - will commit those fixes in a
>>>> bit), the code size drops to 1349696 bytes.
>>>>         
>> Wow, that sounds very good.
>>     
>
> The NDS build I did ran Monkey Island 1 perfectly (for about 10
> minutes of playtime), but clearly that's not an exhaustive test.
>
>   
I encountered several problems.  One was in the GUI, and prevented 
ScummVM from booting (this may well be gone with the new GUI code).  
Another occured during the intro of Gobliiins.  A third problem seemed 
to occur deep inside the scripting engine, as I was unable to use one 
object on another to solve a puzzle.  This was in The Dig.  So it's not 
something you'd notice with a few minutes of testing.

I managed to get around these by turning off various optimisation flags 
individually.  If you want, I can dig out the exact command line I 
used.  I'm not sure this solved all the issues, but it seemed to with 
the testing I did.
>>>> There will be a speed penalty of course, but hopefully we can
>>>> tweak the compile so that speed critical bits stay in ARM ?
>>>>         
>> The ARM build system already overrides our default .cpp compiler
>> rule, just to be able to apply optimization settings only
>> selectively. It should be quite easy to adapt that; if necessary,
>> we can decide for each file whether to use -O / -O2 / -O3, whether
>> to activate thumb mode, and more.
>>     
>
> I was thinking that we might want to keep the core in ARM mode (for
> speed), and the engines themselves in thumb mode?
>
> Or (maybe better) put everything into thumb mode, except for
> particular files that a) cause crashing, or b) are speed critical
> (though I suspect I've ARM coded the biggest speed critical bits).
>
> I'd do some more tests, but I'm fairly busy with RealWorld stuff, and
> the compiler's messing me about - see followup mail.
>
> Robin
>   

If we can solve the compiler issues, it would be great to have things 
running in Thumb.

Unfortunately, all Scumm games except MI1 crash loading resources my 
current trunk build, so I can't really work on much at the moment.  
Also, in MI1 when I hit pause, ScummVM asserts trying to draw the pause 
menu off the bottom of the screen.  I'm looking into the resource 
loading crash at the moment.

- Neil




More information about the Scummvm-devel mailing list