[Scummvm-devel] Re: ScummVM: Plugin question, GP32 backend.

[Max Horn]

Am 07.05.2004 um 20:42 schrieb John Willis:

> Hi Max,
>
> Sorry to mail you off devel but I thought this was a fairly trivial 
> question
> (considering the focus of the list currently)

I still thin this should be on the list, so I am CCing it there. Others 
may want that information, too.

>  and it made sense to speak to
> you directly as I understand the plugins are your brain-child.
>
They are indeed :-)

> The new GP32 backend is coming along well and it not far off being 
> fully
> useable against CVS (just a few bugs to sort in internUpdateScreen and 
> a few
> of the other newer oSystem patches). It's mostly hacked off your SDL 
> backend
> with a chunk of GP32 specific ASM and code added in so it is not a very
> elegant hack ;-).

Just to clarify this, the SDL backend is not mine, other people wrote 
it long before I joined the team (though I did make a lot of changes to 
it over the time, some very fundamental :-).


> In simple terms I get the view that plugins are dynamically loaded 
> modules
> that replace the statically linked (and memory hungry) game engines.

They are. Actually, these days ScummVM is always built with Plugins, 
you only get to decide whether they are all static linked or dynamic 
linked (hypothetically, we could even allow a hybrid approach, were 
some are static linked and some are dynamic linked... though I don't 
see why we would want to...).

The nice thing is that for most of the code, it's completely irrelevant 
and transparent which mode is being used.


>  With
> that in mind my question is how would I go about implementing plugins 
> in the
> GP32 backend (what should I read up on?), I am not a great coder by 
> far but
> I would really like to look at ways I can get all the engines into the 
> GP32
> without having to compile multiple binaries.

You need to find out if the GP32 supports some kind of dynamic linking 
/ loading. Hypothetically you could even write your own dynamic linker 
/ loader, but that might be a lot more trouble than you are looking 
for... While the plugins only need to provide three symbols to the main 
app (the host). That's easy to implement in a self made loader. The 
difficult part is that the frontends/plugins need to access a lot of 
symbols from the main program. So real dynamic linking is needed.


>  I already store GP32 specific
> stuff (pre-config menu etc.) in another file and read from it at 
> runtime to
> save having extra stuff in the heap.
>
One thing that is vital to understand: It is not possible (currently, 
at least) to load plugins on demand when a given target is accessed. In 
fact right now the loading of (dynamic) plugins is rather dumb: it 
looks in a fixed location and tries to load all the plugins it finds 
there.
Extending this to be configurable (e.g. via the config file) would be 
rather trivial.
Extending it to allow "load on demand" would require far more changes, 
esp. conceptual. That's so because the host app really knows nothing 
about the plugins - including that it doesn't know which targets that 
plugins supports (and of course the game detection is also done by code 
in the plugin).
Changing that would require a conceptual change; e.g. splitting the 
plugins into two parts, one with the target list / game detector, and 
one with the plugin. Or maybe keep the target list/detector code in the 
host app.



Cheers,

Max