[Scummvm-devel] TsAGE engine and Geekwad

[Johannes Schickel]

On 11/01/2011 12:24 AM, Paul Gilbert wrote:
>
>     plugins for ScummVM. Thus projects like scummvm-misc, or scummvm-rpg
>     could be easily integrated at run-time. I even would vote for
>     supporting of such projects on our project facilities, just like we do
>     for Residual. I.e. provide cross-linking, server space, hosting etc.
>     Just let have ScummVM to be focused on adventures.
>
> What I would like to encourage is to work on support for external
>
> This would be an excellent step for ScummVM, IMHO. It's becoming a 
> more generalised cross platform game framework, and even if we don't 
> provide official distributions with non-adventure game plugins, it 
> would allow other developers to at least make use of the framework and 
> be listed; this would effectively allow users to play extra other 
> games as people support them. There have also been several other 
> engines previously, such as my Gargoyle engine, Another World, Little 
> Big Adventure, etc. in various states of completion.
>
> On a final note, I've never actually looked at the existing plugin 
> code, so maybe someone can tell me.. what's the current state of 
> plugin functionality? Is there more that needs to be done to 
> effectively support them? Or is it just that some systems don't 
> support plugins yet? Will ScummVM support plugins out of the box, even 
> if other engines are statically compiled in?

In theory that's a sound idea. But let's face the truth we would have a 
lot of extra work when we would declare ourself an official framework. 
At that point we would need to keep our API stable across versions, keep 
backwards compatibility if possible, extend plugin support if we want 
third-party plugins to work with our main binary. That would increase 
the workload on the backend/middle end code by a lot. Furthermore it 
would result in additional bloat due to possibile compatibility layers, 
which take extra memory etc. This isn't really optimal for our ports 
with already low available memory.

On the other hand we could just care a damn about compatibility with 
plugings and break our API whenever we would like to. This is the easier 
solution. But honestly I would hate that. It's totally contrary to the 
idea of being an universal framework.

About the plugin state itself, it somewhat works. It of course doesn't 
do any proper checking whether the versions match (read that as none at 
all). When it comes to supported platforms. One big issue is on the 
Windows platform, where we can only support plugins via MinGW right now. 
That is because we rely on backlinking which DLLs don't support without 
nasty tricks, which I only got to work with MinGW ever. And yes it 
should be possible to have both statically compiled engines and plugins 
at once, don't ask me how it decides which one to use if we have SCUMM 
builtin and another SCUMM plugin though ;-).

Anyway I'm not really objecting to making ScummVM a framework one day. 
But I would rather want to fix a few API pieces beforehand. So for now I 
am really against any move to make us officially a framework. But in 
fact improving the plugin system etc. one of the long standing things I 
wanted to do on ScummVM ;-).

// Johannes