[Scummvm-devel] Memory consumption in GUI branch
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.
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.
More information about the Scummvm-devel