36
edits
Difference between revisions of "OpenTasks"
m
Updated loadable module task
(→Audio related tasks: Restructure things a bit) |
m (Updated loadable module task) |
||
| Line 84: | Line 84: | ||
=== Implemented support for loadable modules on small devices === | === Implemented support for loadable modules on small devices === | ||
''Technical Contact'': [[User:Fingolfin|Max Horn]] | ''Technical Contact'': [[User:Fingolfin|Max Horn]] | [[User:Bluddy|Yotam Barnoy]] | ||
''Background:'' | ''Background:'' | ||
| Line 90: | Line 90: | ||
ScummVM by now contains about two dozen engines for different adventure games. Each of these takes up lots of storage space in the ScummVM binary, and hence also RAM, even if not used. Since both are scarce resources on some of our smaller targets (e.g. the Nintendo DS, which only has 4 MB RAM), this leads to problems. Some of the ports work around this by shipping multiple ScummVM binaries, each with a different subset of engines. This is not ideal, as it means more work for the developers and is confusing to users. | ScummVM by now contains about two dozen engines for different adventure games. Each of these takes up lots of storage space in the ScummVM binary, and hence also RAM, even if not used. Since both are scarce resources on some of our smaller targets (e.g. the Nintendo DS, which only has 4 MB RAM), this leads to problems. Some of the ports work around this by shipping multiple ScummVM binaries, each with a different subset of engines. This is not ideal, as it means more work for the developers and is confusing to users. | ||
Putting all engines into | Putting all engines into loadable modules reduces memory usage, as this way during game play only a single module needs to be in RAM. ScummVM itself is prepared for loadable module support. In fact several of our ports, notably the Windows, Linux and Mac OS X ports, already support loadable modules. This is easy for them as the operating system already provides loadable modules. But this is not the case on systems like the Dreamcast, Nintendo Gamecube & DS & Wii, the PlayStation Portable, Symbian and others. | ||
''The Task:'' | ''The Task:'' | ||
Implement support for loadable modules for at least two "small" targets where this is currently not possible. For the Dreamcast, Marcus Comstedt solved this by implementing [http://scummvm.svn.sourceforge.net/viewvc/scummvm/scummvm/trunk/backends/platform/dc/ a module loader] on his own. You | Implement support for loadable modules for at least two "small" targets where this is currently not possible. For the Dreamcast, Marcus Comstedt solved this by implementing [http://scummvm.svn.sourceforge.net/viewvc/scummvm/scummvm/trunk/backends/platform/dc/ a module loader] on his own. Yotam Barnoy built on Marcus' work and made [http://scummvm.svn.sourceforge.net/viewvc/scummvm/scummvm/trunk/backends/platform/psp/ a similar loader] for the PSP. You should probably use this version as a starting point. | ||
The module loader consists of a [http://sourceware.org/binutils/docs-2.19/ld/Scripts.html#Scripts linker script] which is used to generate custom loadable modules "manually". Furthermore, we use a custom loader for [http://en.wikipedia.org/wiki/Executable_and_Linkable_Format ELF binaries] which takes care of the run-time linking. | |||
You would have to adapt | The original Dreamcast code is for Sh processors, and the PSP code runs on a MIPS processor. You would have to adapt these to generate and load ELF binaries for ARM processors (for Nintendo DS, WinCE, Symbian, GP2x), PowerPC (Nintendo Wii & Gamecube), or the PS2's version of the MIPS. | ||
Ideally, your code should be generic enough to be usable for all platforms. With two examples of the loader already in existence, this should quite doable. | |||
Another factor to consider is that should you wish to build the loader for very memory-starved platforms such as the Nintendo DS, you will have to deal with an issue within the ScummVm architecture. Currently, the loadable modules are all initially loaded into memory. When a game is chosen by the user, the irrelevant modules are erased from memory. In order for the modules to fit into the limited Nintendo DS RAM, this method will have to change -- only one module should be loaded into memory at a time. | |||
''Required Skills:'' | ''Required Skills:'' | ||
| Line 104: | Line 108: | ||
* Good C++ skills. | * Good C++ skills. | ||
* Some knowledge of the ELF binary format (great documentation is available on the net, start e.g. [http://en.wikipedia.org/wiki/Executable_and_Linkable_Format at Wikipedia]). | * Some knowledge of the ELF binary format (great documentation is available on the net, start e.g. [http://en.wikipedia.org/wiki/Executable_and_Linkable_Format at Wikipedia]). | ||
* Any of the listed "small" devices (Nintendo DS, Wii, Gamecube, PS2 | * Any of the listed "small" devices (Nintendo DS, Wii, Gamecube, PS2, GP2x, any WinCE or Symbian device supporting ScummVM, ...) -- ideally multiple. Or figure out how to setup compilers for them. | ||
* Basic knowledge regarding the target architecture, be it [http://en.wikipedia.org/wiki/ARM_architecture ARM], [http://en.wikipedia.org/wiki/PowerPC PowerPC], or [http://en.wikipedia.org/wiki/MIPS_architecture MIPS]. | |||
=== Small Devices Backend === | === Small Devices Backend === | ||