[Scummvm-devel] ScummVM 0.10.0 tagged with tools

Max Horn max at quendi.de
Mon Jun 18 01:43:13 CEST 2007


Am 18.06.2007 um 00:02 schrieb Lars Persson:

> Hi!
> As I see it there are four main issues, some which are easy to  
> resolve, some
> which is abit trickier.
>
> - Scummvm is getting bigger. Getting all those engines into one  
> single build
> for pda type devices, are putting memory, and even linking at  
> large. For
> example for the 0.9.1 release build exe was around 3 mb, the build  
> I tried
> to day with all engines required, ended up at around 4mb. When this  
> binariy
> was loaded, the amount of memory left to the actual game, was  
> around 1-2 mb
> less than before. This is easy to handle by doing different builds for
> different engines (or group then together). For symbian svn builds,  
> we have
> been doing separate builds for each engine to let users have the  
> possibility
> to use smaller engines.

Do you already use plugins for the Symbian port? If yes, just state  
so and then ignoring the following paragraph :-).

If not, I wonder if it would be (a) possible and (b) helpful for the  
Symbian port to get plugin support then? Or is total storage space  
the problem here, as opposed to RAM? Because at least the latter can  
be overcome by dynamically (un)loading engine plugins.
Even if that's not the case, going with plugins might be helpful  
because you could allow users to delete individual engine plugins  
they don't need.


>
> - Compiler support. Actually ScummVM builds almost ok with the 2.95.3
> compiler I'm using. There are two issues, one with a large comment in
> compresedsaves.cpp (how now that can be a problem I can't see),

Do you mean backends/saves/compressed/compressed-saves.cpp ? What  
kind of problem is that?


> and in
> plugins.cpp where the #define statement for each plugin sometime  
> causes
> problems (seems like my compiler has a problem with one define not  
> beeing
> included and then it goes bonkers.) Also when compiled I see that I'm
> getting some hangup at times.
>
> - The alignment issue. I made a small app which patched the 0.10.0  
> sources
> just to be able to do some on device testing to see if I could make a
> working build for the older devices.

What did you patch? You mean you replaced the code which relies on  
#pragma pack?

>
> Yes I can could make the build but when I started testing the  
> builds, they
> where just to unstable to make a release out of them. Now the thing  
> about
> unstableness is not just a thing about alignments, but also some of  
> the
> complexity of the code that has grown, for example the game  
> detection. Also
> I suspect that the code is not 100% correctly compiled to run  
> properly,but
> this is really hard to deduce.

So this would be caused by compiler bugs then?

> As I noticed on UIQ3, using -O4 flag, was
> generating code not running properly, whilst -O2 worked fine (UIQ3  
> and S60v3
> is using GCC 3.4.3 compared to the older 2.95.3)

Offtopic, but: -O4 ? All regular GCC versions only go up to -O3  
(there is even a FAQ talking about the "-OX for large X" myth  
somewhere, I believe :-)

>
> So today I tested GOB1 and AGI games on my N-gage, both games  
> started fine,
> but the initial loading was long and trying to start an non- 
> existing (non
> supported game) took also long time. But once in game it run quite  
> nice,
> eventhough it had its moments of crashing at times. (And this is after
> having 4mb free after starting scummvm, and a processor running at  
> 103 Mhz)
>
> What is my conclusion of this:
> Memory requirements for ScummVM has risen. Both from EXE size and  
> data size
> required, and any PDA should have at least 15 mb free to run  
> happily (which
> includes all S60v3 and UIQ3 devices, but almost none of the older  
> devices).

Aye. As for the number of engines, well, can't do much about that  
(except for plugins, see above). If the memory requirements of  
individual engines increases, though, that's bad :/. All developers  
are of course strongly encouraged to optimize memory & CPU usage.  
Like Knakos recently did with the predictive input code changes.

> Processingpower requirements has also risen abit, mostly in the  
> area of the
> launching UI. Today I would recommend at least a 200 MHZ ARM  
> processor for
> happy gaming.

Are you using the regular UI? Personally I feel that it is rather  
sluggish even on my PowerBook G4 1.5Ghz, at least when building a  
regular (non-optimized) build; there are various relatively simple  
optimizations that could help a lot in this area, I think.


> So ScummVM runs happily on the latest revisions of devices, and  
> thats is the
> current goal, mobile phones are getting old quite fast, and thus  
> support for
> older SDK is not really up to date which makes it alittle bit  
> impossible
> when...

Maybe we should get Phone companies to sponsor us, then, after all we  
encourage people to upgrade to newer phones with each release ;-).

>
> ScummVM is evolving, and so am I, trying to get as many engines  
> running as
> smoothly as possible, newer devices (E90 and P1i) will see FT and  
> even COMI,
> Sword 1 and 2 running smoothly, when processing power and  
> resolutions are
> getting higher.All this without putting to many constraints on the  
> engine
> and common developers. Instead I'm trying to adopt, using the right
> compiler, with the right settings.
>
> None of this work would be possible without all the hardwork of  
> everyone
> supporting ScummVM, regardless of its all the developers, or the  
> users which
> actually gives you the right feedback (yes there are those. ;-) )
>
> So all I am hoping for, is the continuation of improvment and  
> progress. And
> this is something that I'm certain of will be there, in one way or  
> another.


I am very glad to hear that and look forward to a hopefully very long  
and fruitful cooperation :-)


Cheers,
Max




More information about the Scummvm-devel mailing list