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: Discussed Wiz problems and made final design decisions concerning plugin loading with mentors, abandoning Wiz as a testbed for now. (http://tonypuccinelli.blogspot.com/2010/06/restructuring.html)
Implement support for loadable modules on the DS. (To be completed by: July 16th)
July 5th-9th: Get Debugging Facilities Set up for the DS, completely code module loader for DS.
July 12th-21st: Debug and test DS (only building one or two plugins) until the module loader is in a usable state.
Abstract parent “ELF Loader” class to be inherited by targets that support loadable modules. (To be completed by: August 6th)
July 22nd-25th: Do the task!
Change Plugin Design (To be completed by: July 30th)
July 26th-30th: Begin Plugin Design Change Work. Complete "First Refinement" and Begin on "Long Term Approach" (see "Plugin Design Change Plans" below).
August 2nd-6th: Complete "Long Term Approach" (see "Plugin Design Change Plans" below).
End of Summmer
August 9th-13th: Code Reintegration Phase/Wiggle Room :-)
August 14th-???: Continue work with ScummVM? ;-)
Plugin Design Change Plans (Subject to Change)
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 :-).