Toneman
| Toneman | ||
|---|---|---|
| Name | Tony Puccinelli | |
| Team Member since | 20/05/2010 | |
| Working on | Implemented Support for Loadable Modules on Small Devices | |
| Personal webpage/BLOG | http://tonypuccinelli.blogspot.com | |
| tony.puccinelli@gmail.com | ||
About Me
I'm Tony Puccinelli, a GSoC 2010 student for ScummVM and a longtime lover of the interactive storytelling adventure games offer.
I will be working on implementing support for loadable modules in ScummVM's PS2 and DS ports (using the ARM-based GP2x Wix as a testbed for the ARM-based DS). I'll also be attempting to abstract a generic "ELF loader".
For a mix of random sarcasm and more specific updates concerning my project, hit up my blog: Pearls on a String
Current Project Schedule
Write a linker script and custom ELF loader to provide full support for loadable modules in ScummVM’s PS2 Port, using the pre-existing PSP code as a starting point.
Completed on June 13th!
Implement support for loadable modules on the GP2x, an ARM target. (To be completed by: July 9th)
June 14th-18th: Get debugging facilities set up for the GP2x. Start coding initial linker scripts/loader. (Continue testing/documenting PS2 work).
June 21st-25th: Tweak Makefile and finish initial linker/loader code. Begin debugging.
June 28th - July 2nd: Continue work on the GP2x Wiz.
July 5th - July 9th: Finish ELF loader for the Wiz.
Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: July 16th)
July 12th-16th: Do the task!
Implement support for loadable modules on the DS with the aid of the ARM-based GP2x code. (To be completed by: August 13th)
July 19th-23rd: Get Debugging Facilities Set up for the DS and make final design decisions concerning plugin loading with mentors (see "Plugin Design Change Plans" below).
July 26th-30th: Begin making necessary changes to GP2x loader/linker to adapt it for DS and altered design.
August 2nd-6th: Continue work on the DS.
August 9th-13th: Finish coding!
Continue work with ScummVM? ;-)
Plugin Design Change Plans
1) First Refinement
The first change can be relatively simple. Instead of loading all engine plugins at once, load one, ask whether it supports the given game. If not, unload the current plugin and load the next one until you find one that supports the game. This could take a lot of time (like if the correct engine is the last one checked), but would be a quick way to solve the memory problem. I plan to implement this, then get the DS loadable modules working before moving on to more refined approaches.
2) Long Term Approach
For a next step, every game target in the config file can be given an "engine=MYENGINE" key-value pair. This way, the right engine plugin can be decided upon right away. If the "engine=" field is missing for a given game, we can just revert to the behavior of the "First Refinement" and automatically update the target in the config file with an "engine" key based on which engine the old behavior detects as correct for the game.
3) Extra Concerns
- Currently, starting a game without a config entry is supported. For example, if you type "scummvm monkey2" and have no monkey2 target configured, it will try to locate monkey2 in the current directory. We can't know the engine this way, but we could again fall back to the "First Refinement" behavior.
- To support "--list-games", we can just load every engine individually and add the output to a list.
- For desktop ports and certain other ports (e.g. Dreamcast) where it makes more sense to stick with the old, unmodified model of loading all plugins from the start, we can certainly just retain that old behavior :-).