[Scummvm-devel] Another plugin question

yotam barnoy yotambarnoy at gmail.com
Wed Sep 9 13:12:12 CEST 2009


On Wed, Sep 9, 2009 at 1:01 PM, Marcus Comstedt <marcus at mc.pp.se> wrote:

>
> yotam barnoy <yotambarnoy at gmail.com> writes:
>
> > I'm in the middle of debugging the PSP plugins and I haven't really
> gotten
> > to the point where this would be an issue, since I'm working with just
> one
> > plugin right now, but I noticed that scummvm_main() has the following
> code:
> >
> >     // Load the plugins.
> >     PluginManager::instance().loadPlugins();
> >
> > which seems to mean that we're trying to load all the plugins at once(?)
> Why
> > would we do such a thing?
>
> Because the plugins also contain the detection code, so unless we load
> all plugins, we will not be able to detect all games.
>
>
I realize that that's an issue. Maybe it would be a good idea to allow at
least the option for the backend to choose to load, detect and then unload
with every plugin.


>
> > I'm wondering how this works in the memory-limited DC?
>
> 16MB is enough to load all plugins, as long as you don't actually
> start any game.  Before the game is started, all the plugins except
> the one used for the game are unloaded, which reclaims the memory
> for dynamic use by the engine.
>
>
16MB (or 24 on the PSP) is enough for now, but it won't be eventually so
this may not be a good approach going forward.

Also, as I said, for the PSP's MIPS architecture this is an issue in terms
of the global pointer register. Even if I could get all the plugins to load
at once (which is doable but requires reworking the current way I'm doing
short section assignments) it a) means that the gp-addressed section might
fill up faster than the PSP's memory does, putting an even smaller limit on
the number of engines b) prevents me from optimizing the PSP by putting as
much as is possible in the gp-addressed section.

Yotam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090909/a4312edc/attachment.html>


More information about the Scummvm-devel mailing list