[Scummvm-devel] ScummVM 0.10.0 tagged with tools

[Lars Persson]

Hi!

>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 :-).

No I'm not using plugins for the Symbian port, Symbian as a special way of 
handling exports in a DLL so that might complicate things, but there exist a 
plugin interface you could use, or even load DLLs dynamically. Depends on 
what entry points has to be exported. Have not look that closely on it yet.

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

Well, the patched 2.95.3 (which has the template support needed for 
Scummvm), had a strange problem with the large comment about compressedsaves 
not beeing able to scan backwards.  Worked fine with the original 2.95, so 
it must be something with the GCC compiler used.
>
>
> > 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?
>

I just inserted the __attribute__ ((packed)) at the end of the structs that 
had to be packed. Only in around 32 files.
> >
> > 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?

I guess so.  Could be the fact that there are some compiler flags for the 
2.95.3 which would make it behave better. The old 2.95 could n't really 
build any kind of code with opts turned on.
>
> > 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 :-)
Well.. I noticed the same thing. Still it was doing something. :-)
>
> >
> > 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.

I'm using the classic UI, it looks nice on 320x200, its pretty and simple. I 
guess I can do some both memory and performance measuring (using memory 
hooklogger for Symbian, and 30 day licence of glowcode for the rest).
>
>
> > 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 ;-).

Actually some people wont by phones, if ScummVM does n't run on them. And 
what gaming engine can say that it has been successfully ported to that many 
platforms?
>
> >
> > 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
>

Best regards
Lars
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Scummvm-devel mailing list
>Scummvm-devel at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/scummvm-devel

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/