[Scummvm-devel] ScummVM size (was: Re: ScummVM 1.0.0: Release status 2009-07-21)

[Johannes Schickel]

Eugene Sandulenko wrote:
> On Mon, 27 Jul 2009 09:44:06 +0000
> Lars Persson <larspp at hotmail.com> wrote:
>   
>> Hi!
>> Just made a test build, and it built ok (using the branch-1.0.0). As
>> usual bigger than ever. Also better I hope. :-D
>>     
> Which made me think over again. We really have to hammer this out and
> start implementing.
>
> We need:
>
>   1. Decouple detection code from engines
>   2. Put this code to "core build"
>   

I guess a plugin could still supply detection information itself? Or 
will we just disallow third party plugins now? At least back then there 
was no decision about FreeSCI merge, it sounded like a good idea to 
allow third party plugins.

Also I guess third party plugins would be a good idea for engines like 
Mohawk etc. So we might have some public SVN repo and maybe create some 
plugin binaries so interested people can test it, before they are in our 
SVN. This might help to prevent rotting engines like M4. (I heard about 
dreammaster's plans to work again on M4, that's great. But currently it 
looks dead :-/)

Of course third party plugins are still not (easily) possible currently. 
So dropping 'support' for it might be just fine. Though I would like to 
hear more arguments for it first.

>   3. Have native ability to build several "specific builds" with
>      support of restricted number of engines.
>   3a. Each such build has to have the "core build" facilities, i.e.
>      ability to detect any game.
>   4. Besides plugins it could make sense if our core system could
>      launch specific builds seamlessly.
>
> That is, there will be 2 paths:
>   a. Engine plugins for those platforms which support it
>   b. Binaries which will be loaded on top of existing one (i.e. POSIX
>      call exec().
>
> Any thoughts?
>   

Do we need splitted detection code for plugins btw.? Couldn't we just 
load one plugin after another when detecting a game on a platform with 
memory constrains? Maybe we could have some cached config option like 
"plugin=scumm" to avoid long wait times on game start caused by trying 
all available plugins.

For a platform supporting dynamic plugins, I guess keeping the detection 
entries in the plugin binary will also save some memory on execution.

// Johannes